Adobe campaign classic External Signal limitation

[supratim320]

Hi Everyone,

We are currently working on a real time implementation where the JSSP will store the data in an interim table and then send PostEvent to an external workflow to process this data.

However, as part of load testing, we are seeing not always the workflow is running smoothly everytime when the JSSP was hit with concurrent calls (e.g.- 4 calls in a min causes the workflow to run 2/3 times).

For ACS documentation, we could see for signal activity: "The activity cannot be triggered more often than every 10 minutes." - is there any similar kind of restriction on ACC external signal usage?

[david--garcia · Accepted solution]

You could enhance the jssp page to query the status of the workflow, and if is currently running then do something.

But,

1. Easiest way taking into account your architecture, would be to let interim event data be handled by another process.

1. Your jssp page will consume the data
2. Your schema will act as an event queue (waiting for a third process to push the data to your workflow)
3. Add a new boolean flag which will mark events as processed by the third process

[supratim320]

Thank you for the reply @david--garcia for your suggestion.

The document says that PostEvent works with a queue, i.e. if the post event is fired, the event will get stored in the queue and then it will get fired when the workflow starts. So, in that case, if all the JSSP calls have reached campaign, all the postevent should have reached as well i.e. - making all the calls, however, the count of workflow run (in the log) did not match. So I am assuming if there is any hard limit on the postevent fire count. Any information on that will be really helpful

[david--garcia]

I believe that happens in the case the workflow is not running, but I will check internally for more info, can you post exactly what sort of behaviour you are facing. and also, whats the average processing time of each event by the workflow containing the signal.

---

If the target workflow is suspended when the method is called, the command is left in the queue until the workflow is resumed.

---