Hi ,

Regarding Broker Subscription flow service.

1. Developed a flow service “A” which fetches data from a database(“DB1”) and publishes it to a publishable document(The publishable document contains a document list ) .

2. Developed a flow service “B” to Subscribe the published document(which contains a document list published by the flow service “A”) and insert into a database “DB2” .

   The “B” (Subscribe) flow service has the below logic.
   i) Subscribes the published document which contains a document list ( published the flow service “A” )
   ii) Loop the document list
   Inside the loop
   Try
   {
   a) Start transaction
   b) Insert adapter (for header table)
   c) Batch insert adapter(for child table)
   d) Commit transaction
   }
   catch
   {
   Invoked - pub.flow:getLastError
   Rollback Transaction

       }
   

3. Created a Trigger “T”
   Which calls the flow service “B” when the publishable documents has data

Works State : working fine if I maintain a correct set of data
Then, Executed flow service “A”
(Internally the trigger “T” calls the flow service “B” and inserts the data into “DB2” correctly)

Issue : If I purposely maintain a wrong set of data.
Then, executed flow service “A”

Internally the trigger "T" calls the flow service "B" and try to insert the data into "DB2", due to some constraint the data is not inserted 
And the Transaction is Rolled back 

[b]But trigger "T" repeatedly calls the Subscribe flow service ("B") and keep on tries to insert the wrong records and rollbacks.

How can I handle / stop the repeated execution of the flow service “B” if wrong set of data maintained ?
[/b]
Regards,
Daniel Sebastian .C

Hi Daniel,

Please check the trigger retry properties and retry interval which might be causing your trigger service to run on failures.

Also check if publishing service is generating publishable document repeatedly which is causing your trigger service to run many a times.

As far as I know if for single document is published then only single subscription should happen if we handled everything in right manner.

Hi Firoz,

The trigger retry property has two types
i) Max attempt reached
ii) Successful

In my trigger

retry until : Max attempt reached
retry interval : 0

Daniel,

firstly, you have not picked the best forum to post this question on. This is the forum for general webMethods announcements. A better forum would be the IS/ESB on: Integration-Server-and-ESB Knowledge base articles, news, Community help, and support forum discussions

To answer your question, if you rollback the transaction, then it is expected that you will get the same message again. Are you in your catch-block also calling pub.flow:throwExceptionForRetry?
What behavior do you actually want if the database insert fails?
Generally you would want it to be logged to the service audit database so you can manually resubmit it later (when you have fixed the data issue). In that case, you don’t actually need the transaction management and try-catch block, as the JDBC service will throw an exception. Just configure service auditing on the top-level service to log on error and include pipeline on error. That should ensure only a single execution attempt for each message.

Share the screen shot of trigger properties showing: Transient error handling settings and outline of your subscriber service.

Also in your subscriber service make sure you have the startTransaction outside the main sequence.

Trigger details attached.

Sub1 is the screen shot of outer flow service, ( In that Sub2 flow service is invoked) yellow color highlighted.

https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files/b206817c5879165dc106c65cfb5cb1557458e936.png 1.5x, https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files/b206817c5879165dc106c65cfb5cb1557458e936.png 2x" data-dominant-color="F2F2F3">

Trigger.PNG382×648 26.8 KB

https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files3/c71ff6e116dd8809edc85ea9ae0a77fc861a9b74_2_1035x642.png 1.5x, https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files/c71ff6e116dd8809edc85ea9ae0a77fc861a9b74.png 2x" data-dominant-color="F5F5F6">

sub2.PNG1099×683 81.1 KB

https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files3/59ea92f8ebc98f4fd3c858380307cf3a48d979d7_2_1035x661.png 1.5x, https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files/59ea92f8ebc98f4fd3c858380307cf3a48d979d7.png 2x" data-dominant-color="F2F1EF">

sub1.PNG1104×706 92.1 KB

Mr. Jonathan Heywood,

In catch block I didn’t invoke pub.flow:throwExceptionForRetry.

(What behavior do you actually want if the database insert fails? ) If any exception occurs in the flow service, it should go into catch block and gets finished.

But now when exception occurs(inside subscription service) the trigger repeatedly calls again and again the subscription service.

My need is, if exception occurs the flow service should go into catch block and gets finished, It should not execute repeatedly.

And can you please elaborate the part
" [Generally you would want it to be logged to the service audit database so you can manually resubmit it later (when you have fixed the data issue). In that case, you don’t actually need the transaction management and try-catch block, as the JDBC service will throw an exception. Just configure service auditing on the top-level service to log on error and include pipeline on error. That should ensure only a single execution attempt for each message. ]"

Because the subscribe flow service will receive a document(which contains a document list ).
And i should iterate(loop over) the document list and insert into the database. So that i perform start and insert transaction inside try and roll back transaction inside catch.

Are you sure that the publishing service is not publishing each instance of the document and it is publishing all the once. The subscriber service and trigger looks ok as there is no retry enabled.

Can you please give a try as below.

Suspend the trigger, enable it again.

Run the publishing service, and disable the publish step of the publishing service and see the behavior.

which wM version you are on ? What fix levels do you posses ??

Hi,

what is the setting for delayUntilServiceSuccess for the publish step?

If set to true, all documents will be published together at the end of the service.
If set to false, each document will be directly published.

See Build-In-Services-Guide for details.

Regards,
Holger