I have created 3 components with JDBC adapter. The following is how I wish they would work:

Component1 reads 1 record from the file and call a st procedure that checks for duplicate data in the tables. If duplicate, do nothing, else publish a document1 (as publishandwait for reply1). It should do the same thing for the next record after it receives the Reply from Component3.

Component2 picks up document1 and do some data massaging and publish a document2.

Component3 picks up document2 and insert into table, and then publish a reply1, which is the same DocType as the reply doc in Component1.

However, when I run them, Component1 publishes the first Document1 and waits forever. Component2 and Component3 do not seem to be triggered at all.

Could someone please tell me what I did wrong with the pulishandwait ?

A few questions to make sure I understand

1. When component 1 is reading from a file, is this an integration component within the JDBC adapter? Reading from an external file?

2. The components are expected to execute in sequence - 1, then 2, then 3? If so, what is the reason to not create the whole sequence as a single component?

3. Publish and wait means to wait for a specific reply to the specific published event … the reply is delivered to the publisher (not published and subscribed by the publisher). The original published event has info that must be used in the deliver for the deliver to come back to the publisher. Is this what you want to have happen?

Mark Thomsen

Sounds like you’re chaining together request/replies.

Component1 sounds okay.

Component2 needs to do request/reply. pub doc2 and wait for reply from Component3. When reply is received, deliver a reply (the same doc type) to Component1.

Component3 should deliver the reply, not publish. The deliver will go to Component2, which will forward it to Component1.

Normally, webMethods will do Component1 for all records, then publish. Do Component2 for all records and then Component3 for all records.

What I am trying to do is run Component1, Component2, and Component3 for the 1st record. Then do the same things for record 2,3,…record by record.

Any subjection on how to do it?

Actually, Component1 is selecting * from a pre-loaded table.

The reason I break this into 3 components is because there are many loops and branches involved and Component2 and Component3 are not required in certain cases. So I publish the Document2 only when Component2 and Component3 are required. I think this will make it easier to manage.

What you said in #3 is exactly what I want to do in Enterprise Integrator.

Any good suggestions?

To be simple, I just want to make sure Component3 is done for record1 before record2 is processed by Component1.

Is this possible?

If I was starting and had the requirements you stated I would break the total processing into several scripted operations. This feature is in EI specifically to allow you to create “subroutines” which can be optionally used and reused within one or more components. Using integration components as subroutines is possible, as you are doing, but is not the intended path.

Given what you are doing I think the recommendation (made by another) for chaining publishandwait, as if you are doing subroutine calls, is appropriate. Component1 does publish and wait where: Component2 subscribes to the Component1’s published event, and delivers the event Component1 is waiting on as the reply. This makes Component1 synchronous with Component2. Do this again between Component2 and Component3.

To deliver an event use the Create Event step in EI to create the reply, and check off deliver instead of publish in properties. When the component is done that event will be delivered to whoever published the triggering event. Do this in Component2 and Component3. The event you used for Component3’s published completion should be used by Component2 for the deliver. Create another event for Component3 to deliver to Component2. (Probably the only new event you need).

If you are going to do a lot more of this I strongly suggest learning how to use scripted operations instead of integration components for modularizing your logic inside a single adapter. Breaking logic into integration components is intended for when you are going between multiple adapters and agents.

Regards,

Mark Thomsen