Event Subsystem

Where is the best place to find out more about the TS event subsystem? I was wondering how to determine what events are "published" out of the box from TS 6.5 and can it be extended if necessary. Also how is a "subscriber" registered to receive those events? I am wanting to do some additional tasks when a file is deleted from TS. I was hoping that "delete" of a file was an event that is published by TS and that I could create a subscriber to receive that event and do my specific needs. This way I'm not changing anything that TS does with the delete function, just adding my additional requirements to the process no matter where the file is deleted (ccpro, ccstd, etc.). Just can't find any details/samples on how this all works. Can anyone provide some insight? Thanks

Find more posts tagged with

Comments

reddyl

You can use TS trigger mechanism to run run a custom script when a asset is deleted. More information of TS trigger mechanism is documented in 6.5 Command Line Tools. I am not sure if you can subscribe to JMS event queue message system as only one process can receive the message from the queue.

reddy

jornduff

I see command line tools to delete workareas, branchs, editions, extended attributes, and deleting a file from workflow tasks. Is there a command line tool that will delete a file from TS?

Michael

On solaris there is one called 'rm' and on windows one called 'del'

Hope that helps

Cheers
Michael

Adam Stoller

On Unix: 'rm'
On Window: 'del'

Seriously - deleting a file within TeamSite is at the OS level - so you use a native OS command to perform the action.
Then you need to submit the deletion to your branch's staging area in TeamSite to complete the operation.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

jornduff

Thanks for the "help" with the delete commands!

What I am trying to do is identify what files are being deleted from TS. The reason is we would like to remove these file from our production application and web servers since they may have been previously deployed there. I didn't want to create my own task to do a "file delete" since I wasn't sure what TS did when it deleted a file other than obviously removing the file. That's why I thinking that I could extend the file delete function by using the event subsystem. I thought if TS would publish the "delete" event, I would create a subscriber to that event to do my additional requirement. Based on fish's comment, I really need to know when a deleted file is submitted to the branch's staging area before I should do anything (i'm assuming the file isn't really deleted until this submit occurs). If that's the case, should I used the CLT "iwatsub" to do something on a submit of a file? If so, any idea how to do this only on a submit of a deleted file and not on an updated file?

Thanks

iwovGraduate

How are you deploying the files to production ? OpenDeploy ?
If so, you can use the dodeletes option in your OD config file which will delete files that are in target, but not in source. (Ofcourse this depends on a bunch of other factors as well about your environment)

Why go through all the trouble of creating triggers and listening to events and all that.

smenon

How is the content being deployed to your production server? If you are using OpenDeploy to do it, then OpenDeploy can also take care of removing the files from your production server if the file was deleted in TeamSite. If you already use OpenDeploy, then creating a subscriber and building custom functionality to do this might be overkill, because that is standard OD functionality.

In any case, for a list of events that are published - they are listed in the TeamSite Admin Guide.

--Sunil Menon
Product Manager
Interwoven, Inc.

jornduff

We have a custom deployment process that allows our TS users to deploy 1 or more data records (xml files) at a time. They select what they want to deploy and the STAGING version of that file (and other related files it references) is copied to a temporary location on the TS server. Then a script runs every so often looking in this location for recent deployments and uses Open Deploy to move all of the files for that deployment to the production servers. We never deploy entire TS editions, it is always a group of files that the users have decided to deploy. Thus the original problem, a user deploys a content item from TS to our production environment and later they decide to remove it from IW. We have no automatted way of getting it off of our production servers.

Maybe there isn't such a thing, but I believe we don't have what you would call a normal TS implementation. I would say that the sites we manage content in IW for are fairly large (approx 80,000 xml files) and very dynamic. For example, we have a requirement that our users be able to have a change to a data record be visable on our production sites within minutes of the deployment. I'm sure others have the same requirements. How is that done?

iwovGraduate

From what I understand about your environment and what you are trying to do, you should be able to do so with OD using doDeletes.

We have a custom deployment process that allows our TS users to deploy 1 or more data records (xml files) at a time. They select what they want to deploy and the STAGING version of that file (and other related files it references) is copied to a temporary location on the TS server. ...

So I assume you are doing a file-list deployment of selected files from TeamSite STAGING area to a temp location on TS Server. Correct ? How is the deployment invoked ?
Is there a workflow involved ?
Or do you have a script that just copies over the files ? If so, how is this script invoked ?

Then a script runs every so often looking in this location for recent deployments and uses Open Deploy to move all of the files for that deployment to the production servers.

Are files ever deleted from this temp location ?
What type of deployment is this ? Filelist ? dir-compare ?.. ?

Why are you deploying to a temp location and then deploying to the production servers ? In other words, you can directly deploy a set of files from TeamSite STAGING area to the production server(s) without having to put it in a temp location.

... in IW for are fairly large (approx 80,000 xml files) ...

100 K files in TS - quite common. No biggie.

... visable on our production sites within minutes of the deployment ...

That is a typical requirement/expectation out of TS/OD and it is very common that TS/OD implementations do that.

jornduff

First of all we are on 4.5.1 and are in the process of upgrading to 6.5. Our initial 4.5.1 implementation was done 4+ years ago by a third party.

I'll try to briefly answer the questions you have about what we do for deployments. First of all we added a custom menu item to the 4.5.1 UI to deploy files. The user selects what files they want to deploy using the checkboxes from the existing UI. When the user selects the custom "deploy files" menu item, it passes the files to deploy to a jsp page. There are some validation rules executed at the start of this page, but assuming everything is ok with the files the user selected to deploy the user has a chance to schedule the deployments of those files in the future (say they want the deployed files to move to production at 10:00 pm tonight). When the user submits this form from this jsp page, the files that are being deployed (and the code will find logically related files) are copied to a specific set of directories on the TS server. A file containing the scheduled date/time requested by the user is also written to a directory. All of this file IO of copying files is done in java code. There is a script that runs every minute or so on the TS server looking for sets of files in these deployments directories. If the date/time of the scheduled deployment is in the future, it leaves it alone. When the scheduled date/time has passed, the script uses Open Deploy to move the files for that deployment to the production servers and removes that set of files. This "scheduling" feature is the reason for placing the files in a temporary location on the TS server.

One question I have to anyone who has a site that is updated multiple times a day is how does your deployment work? Is an edition made each time and that edition is deployed to the production servers? Or can a small group of files be deployed by themselves?

Johnny

A couple questions regarding reporting and the event subsystem.

A) reporting

I just want to clarify what is "new" or additional when reporting is installed compared
to what TeamSite 6.5 comes out of the box with

Below is quoted from the admin manual...
The reporting service infrastructure consists of the following modules:
(1) A new messaging library......
(2) A new proxy service......
(3) Interwoven Event Subsystem.
A report module......
The Reporting UI....
----------------------------------------------

Now are points 1,2,3 updated or "new" when reporting is installed or is the manual simply referring to the TeamSite 6.5 components.
I'm asking because I interpret those lines (including the leading paragraph) as describing "new" software that is specific to reporting, but I thought points 1,2,3 were not specific (exclusive) to reporting.

Event subsystem

In reply to:

In any case, for a list of events that are published - they are listed in the TeamSite Admin Guide.

--Sunil Menon

Sorry, but can you describe where I can find these in the admin manual.
What I did find was a paragraph that documented a few but not all.

Quoted from the manual...
.....TeamSite server events include (but are not limited to):
CreateBranch
Submit
TaskActivate
------------------------

If there is a documented list of all events:
A) Does this mean there is a supported way to add our own subscribers to the event subsystem? Is there documentation for this?

Are we able to at least create a subscriber table which never gets consumed (the subsystem publishes all the
events to a table and never removes them)

Your help would be appreciated.

John Cuiuli

smenon

You are right - Items 1) 2) and 3) are actually the OOTB TeamSite 6.5 components (that are specific to the event subsystem) and not updated or new components for reporting.

Regarding documentation of events : If you look under configuring reporting - there is a list of archived events that are captured for reporting purposes. This is essentially the list of events that are published by the event subsystem and so you should be able to work with that list.. This in on pg 152 of the Admin Guide.

I don't believe that there is any Interwoven documentation for how you can add your own subscriber - but since the event subsystem is built on top of OpenJMS, you should be able to get that documentation from OpenJMS at http://openjms.sourceforge.net/

--Sunil Menon
Product Manager
Interwoven, Inc.

Johnny

ahh sorry, I was searching for the wrong terms, you're right its all there.
I was thinking in terms of the event subsystem rather than reporting.

The database schemas, and "reporting" events .. are they interchangeable with the OpenJMS configuration?

Regarding the use of the OpenJMS, before we consider that can we have word that this is a publicly exposed component.

Looking at all the detail provided in the manual (mostly under reporting), it seems to suggest that this is the case, but I'm not too clear if it's actually stated that this is a publicly exposed component (and thus its exposed features will be supported through the product releases).

Thanks for the details.

John Cuiuli

smenon

What do you mean by "publicly exposed component" ? Are you talking about the list of events or are you talking about the event subsystem publishing methodology?

--Sunil Menon
Product Manager
Interwoven, Inc.

Johnny

The latter - event subsystem publishing methodology.

I haven't seen it mentioned anywhere that it's internals are available for us to use in custom applications.

(It could well be explicity stated in the manual somewhere, I could have overlooked it)

John Cuiuli

smenon

Unfortunately, we haven't published the event message format and the methodology to write your own subscriber. That is the primary reason why we haven't documented the fact that you can write custom applications against it.

At this point, we haven't standardized on the messaging format in order to make it a supported interface going forward. In case we change the format in the next release, our own internal subscribers such as indexing, reporting and DAS can be modified easily. Having said that, I don't believe that this will change dramatically in the next release, but unless you are willing to take that chance, I wouldn't recommend that you build a custom application on it today.

--Sunil Menon
Product Manager
Interwoven, Inc.

Johnny

Thanks for the feedback.

In a previous post you mentioned that we should be able to do it - but now you are raising a serious point. I'm glad I asked - now it's clear.

Thanks again

John Cuiuli

smenon

Sorry about the confusion.. In theory it should be possible, but I checked and realized that we hadn't officially documented the format which would have made it a supported interface. I just wanted to ensure that you are aware of the consequences if you build a custom subscriber..

--Sunil Menon
Product Manager
Interwoven, Inc.