I had a requirement of developing a trigger which should subscribe 20 Docs(even if >20 got published) remaining should be subscribed in the next turn
i’m really wonderring abt the peculiar behaviour of the trigger(regarding the subscription of docs) some times its subscribing 13 at a time then remaining 7 (if totally 20 docs are published) some time 3 ,1,3,1 combinations… tottaly each time different
can any one please guide me regardng this
i have given
Capacity-20
Refill level-15
Acknowledgement Queue Size1
Processing Mode Concurrent
Max execution threads 20
Can’t control the trigger thread execution like that. 20 concurrent threads only means that 20 concurrent threads can process at the same time. It does not mean you will have 20 threads at one time, just that you can. You could try capacity 20 and refill at 0 but that is still not going to guarantee what you are trying to do.
20 concurrent threads is a lot. Do you have that much volume? What is your flow service execution time? I think you might be trying to get a little to granular with your trigger control. Could you explain in a little more detail what you are trying to accomplish by this?
i will be keep on getting documents which i have to subscribe using trigger
and i have to send these docs to external system,means if i get 40 docs my trigger should 1st process 20 docs and the remaining 20 next time
I think we understand exactly what you’re looking for, but:
As Mark pointed, you cannot achieve that using trigger configuration.
What makes 20 the magic number?
If you’ve been instructed to deliver documents to the external system in groups of 20, then you’re pursuing the wrong solution. The trigger and trigger service will process 1 document at a time, regardless of the trigger configuration. With a concurrent trigger, multiple threads may be running but each thread will be processing 1 document at a time.
Let us know if you’re trying to gather docs in groups of 20. There are several techniques for doing so (though you should have a compelling reason for doing so because it introduces complexity).
Even if the publisher publishes docs in groups of 20, that won’t change how the subscriber processes them. Also, it isn’t a good idea to try to modify a publisher to meet the special needs of one subscriber.
This raises a question for sujith: Is there more than one subscriber? If not, why is pub/sub being used?
One approach to batching is:
The subscriber writes received docs to a file or a DB table or maybe the IS repository.
A scheduled task wakes up periodically to gather 20 docs at a time and send them to the external system.
