call dynamically pub.flow:invokeService

I need some advice as good pratice

I explain : for my service I have systematically the same code :
I save all calling in database.

  • I create an instance in my database for the service called
  • I check in database if another instance doesn"t running
  • If it is the case I stop my service
  • If not I continue
  • I put a tru catch for my service
  • If I reach the end of the try without failure I save my flow as finish with succeed
  • If I reach the catch I save my flow as finish with failure.
  • I do the same things exactly for all my services.

I have an idea do a generical service wich do all the same things and call the service pub.flow:invokeService to call dynamically a service for each flow. Each flow call a different service but in my database for each flow I save the service I will called.

I want to know if it is a good pratice and if it is not a problem for response time or other problem linked to performance ?

Hi Vital,

can you describe your use case in detail please?

The general logging is done by IS Core Audit logging ootb.

To make sure, that only one instance of a service is running at a time you can use publishAndWait/publishReply combination.


Hello Holger,

For all my flow:
I have a flow in which select n records
In this flow, for each record, we put in in document called PIVOT, put this PIVOT in jms and put it in Topic.

I have a flow out with trigger on the topic, I put the document from the jms message and I deal with message.

So each time, a flow is launched, the flow in is called one time and the flow out is called n times (each time for the n records selected).

Problem : I don’t know when it is finished.

So I created some database when I specified flow in, flow out, number messages In (the count of the select), number of message out (the number of calling flow out and when it is finished).

Thanks to that, I know where a flow is finished.

But each time I made a flow in this way, I need to create my flow in, read database, knowing the that the flow is available (it means that a instance of flow (flow in and out) is not running, write in database). It is every time the same code.

My idea is to write in my database the servicecalled for each flow in and called the pub.flow:invokeService with the name of the flow (read in database).

It means for all flow I want to create I called systematically the same service but the name of the flow change each time. The invokeService do the job like a delegate in object code.

But I want to know it is a good practice.

I’m not sure whether this approach is the best for your particular problem (haven’t understood the case well), but we did use this approach (calling services per name and doing something else in the calling/wrapping) service with no problems at all.


Like fml2, I struggled a bit to understand the use case so I’m going to focus on the part I did understand in the hopes that by addressing that, I will answer your overall question and eliminate the need for you to invoke a service dynamically.

It sounds like you need to select n number of records from the database and publish each record. The subscribing service then does something with that record. However, the subscribing service also needs to know when it has received the last record so it can do something else, is that your main problem?

If so, then it’s quite simple. You can accomplish it in a couple of different ways but this would be my suggestion:

(1) Create an additional publishable document type that we’ll call CompletedDoc but call it what you want
(2) Make sure your trigger is serial
(3) Add a new condition to your trigger so that your trigger also subscribes to the CompletedDoc and calls a service that will contain the logic for what you want to happen when all records have been processed
(4) In your publishing service, implement something like this:

    ---- SELECT x records from the table
    ---- IF no records returned, EXIT the loop
    ---- LOOP over records
    -------- PUBLISH each record
  • PUBLISH CompletedDoc document

Because your trigger is serial, it is guaranteed to only receive CompletedDoc after all records have already been received. Makes sense?