There are multiple events in which metadata for a give content item may change.
Like when a new version is added, when some metadata is changed so you will need to capture multiple services.
two of them which come to my mind are Update Doc Info and CheckIn New Version.
you may want to give more thought to your scenario and figure out if there are any more cases in which metadata may get updated.
> a content item has completed it's checkin cycle and receive the dStatus: RELEASED value
first of all, RELEASED status might not be necessary for your situation
1. it is possible to define Released Date to the future. This will mean that an item's revision will be in DONE status, and wait until the day comes to changed to RELEASED. If you have more revisions of the same item, there can be several RELEASED revisions, but only one of them will be active (e.g. indexed for fulltext search); plus, you can have several more 'future' revisions in DONE or other states
2. when an item enters a workflow, it will be in the REVIEW status
3. in a similar way, you might be interested also in revisions entering EXPIRED or DELETED status
> inform another system of the contentID and metadata values
4. if you have ContentID (dDocName), or better dID - dDocName is unique for a content item, dID is unique for a revision - you should always be to obtain the current metadata via DOCINFO* services. Depending on your use case (can metadata be changed in UCM?) it might be wiser not to copy metadata.
Out of my head I don't know if there is a java filter event where changing status to RELEASED can be caught. You can try to find out yourself - if you turn on tracing on services (see Troubleshooting Oracle WebCenter Content - 11g Release 1 (11.1.1)) you will get quite a chatty report (incl. back-end service calls) where filters are listed as well. You can use the scenario 1. (future Released Date, where you will move the system date in the future). However, I think there are other options:
- use the subcriptions (Managing Subscriptions and Notifications - 11g Release 1 (22.214.171.124.0))
- get a report of released items
- just get dID/dDocName during the checkin, and then, if necessary, check the status via DOCINFO*
It might be helpful if you share more details about the other application and what the business purpose of the integration is.
P.S. I tried the 'future date' scenario and the status is not changed until I rebuilt the collection index in the Repository Manager. No specific filter event detected. So, my suggestion is to consider the mentioned alternatives....
Hi Swapnil Solanki,
I know there are different scenarios that will make the metadata change for a content item, however, I'm not interested in the general metadata changes. When a document's dStatus field is set to Released it means that it has gone through all the processes whether it is a workflow/conversion/web-viewable etc. and the Indexer has released this content item.
Since the metadata is in the database, the Indexer updates this metadata field using a system call/event/trigger and that is what I don't know to call it. I don't need to specific thing (though I won't complain) but I need to know what the action is called when the Indexer updates a field.
Example: in Java you can register a listerner for an event or create an exception. I don't know what these actions are called in the Webcenter content context. As previously mentioned: in Java you trigger an event during checkin but in the Webcenter content context you create a Java filter for the checkin.
Globally and generically I would like to register a listener for a specific contentID on dStatus change (Released). How it gets to that state I'm not interested in, I'm interested in the state change.
Thank you for your reply. The other application is not the issue and the only thing we have to worry about is sending a webservice when a content item went through its checkin lifecycle and is dStatus: Released.
The Released status is necessary in my situation that is the status I need to send out my webservice on and how I notify the other application of the information is also not the issue of my question.
I'm going to read up on the intradoc.indexer.IndexerState and on the filter postIndexingStep since these sound as though they might contain the information I either need to help me in the direction I need to go.
Again thanks for the links to the docs I'm reading them now. Also I realised I never mentioned that were are on 11g Release 126.96.36.199
Have a nice day,
just noticed that for subscriptions I provide a wrong link. The correct one is:Managing Content - 11g Release 1 (11.1.1)
You didn't mention why you need RELEASED state and why you need it the moment the item changes to that state. But following just the requirement my choice would tend to subscriptions.
Anyway, check that the way you decide for applies for all use cases. The release should not be relevant here - AFAIK, this has not changed for quite a long time.
Thank you for the link. This is not what I'm looking for but the idea is there. I need to kick off an automatic process (a webservice) once the document status has changed to RELEASED. I did explain why I need the RELEASED status in my first post.
The subscription notifies via email once a document has been revised, and as I said the idea is there. An email notification however would require a manual element of activating the webservice whereas a listener on the RELEASED event can do that automatically.
I will keep the link to subscriptions for any future use, thank you for the information.
I tried to analyse subscriptions to see if there is any filter event, or a service that you could use (hook on the event, or overload the service the call what you need as well), but at the first glance I could not find anything useful, except event notifySubjects, which is perhaps a bit too general.
> I did explain why I need the RELEASED status in my first post.
If you are referring to
> I want to know when a content item has completed it's checkin cycle and receive the dStatus: RELEASED value.
this is WHAT you need, not WHY.
My point is, what happens if you get this information 5 minutes, or an hour later? With given scenarios you already know that reaching the RELEASED status can be almost immediate, or can take days. You have a lower bound (check-in event), and you could easily create an upper bound (call GET_SEARCH_RESULTS for specific metadata - e.g. what new items appeared in the last hour - and check whether the item is present in results).
I assume that you already have enough info to achieve what you wanted, but there might be more convenient ways to fulfill your business goal, but with different means.
In my first post I did mention:
"When this content item status is set to released I need to kick of a webservice and inform another system of the contentID and metadata values". I think this consitutes as a WHY.
I need to know when the dStatus has been set to RELEASED. I know it can take time I don't need to have a time limit. I don't want to poll I honestly just need the term used by Oracle for events and listeners.
I don't expect the community to solve configuration and my workflow. I just need the term to know what to search for. And no I don't have enough info to achieve what I want because I don't have the term that Oracle use for registering a listener on an event.
> "When this content item status is set to released I need to kick of a webservice and inform another system of the contentID and metadata values". I think this consitutes as a WHY.
No, it does not. At least, not to me to be able to evaluate alternatives. You don't mention anything about the purpose what the other system will do with the sent information, which could suggest necessary timing.
> I want because I don't have the term that Oracle use for registering a listener on an event.
I sense an issue here. It seems that you are looking for a way how to listen (in a 3rd party app?) to an event. This is not how events work in UCM. I'd recommend you to go through samples of components at How-To Component Samples for Oracle UCM 11g | Bex Huff.
Events are fired automatically by the system when a certain situation occurs (e.g. an item is being checked in, or a notification email is being sent as in our case), and AFAIK all you can do is to 'hook' a Java code onto an event, usually referred to as a 'filter' as it implements an interface called FilterImplementor. Filters, however, are server-side, and you need to implement then in server-side components (you will see at least one sample among HowToComponents).
So, once you get familiar with filters you might want to "kick of a webservice" from it. It will have to be "another system's" webservice. Alternatively, you could broadcast a message into a service bus, if you have one.