10

In short my question is: Why does it usually take significantly longer than the specified timeout time to progress from one state to another in an engagement plan?

Detailed issue: A user has been added to an engagement flow and after the session has ended I can verify it in the EA supervisor and in the xDB. I have a simple engagement plan in which the first step has a timeout of 1 minute. I would expect that this timeout is more or less precise but I usually see that it takes somewhere between 10 and 20 minutes to actually progress to the next state. It eventually progresses which I have verified by using a simple action that sends be a basic mail, but it takes a very long time to do so.

Note: I am using Sitecore 8.1.3

(This question is a follow up question to Engagement Plans: Why is a user not added to an engagement plan until the session of a user is timed out? which is concerned with why users are not added to engagement plans until session ends)

| improve this question | |
  • 3
    Have you checked that the processing agent in Sitecore.EngagementAutomation.TimeoutProcessing.config is set up with an Interval that is short enough? – Dmytro Shevchenko Oct 13 '16 at 9:08
  • 1
    Also, this may happen when the contact gets locked by another session—i.e. if they finished one visit and started another immediately. – Dmytro Shevchenko Oct 13 '16 at 9:11
  • @Dmytro: The interval is set to <Interval>00:00:10</Interval>, but the session lock could be the issue. So if the contact is locked by an active session, he cannot progress from one state to another? – pwind Oct 13 '16 at 9:13
  • 2
    Exactly. The automation worker will wait until it can get an exclusive lock on the contact before it changes any automation states. – Dmytro Shevchenko Oct 13 '16 at 9:14
  • @DmytroShevchenko: I will look into it and get back as soon as possible, but it sounds very reasonable. I think that the timeout values are a bit misleading for an editor/marketeer, because they actually expect it to work . They don't know anything about sessions, locks etc. – pwind Oct 13 '16 at 9:16
9

Automation worker running interval

The automation worker is the agent that processes automation state changes with a certain interval.

The first thing you should check is whether the automation worker is executed frequently enough. The default is to run it every 10 seconds, which is a good value for your needs. The setting is located in the configuration file Sitecore.EngagementAutomation.TimeoutProcessing.config, under configuration/sitecore/automationWorker/Interval:

<automationWorker type="Sitecore.Analytics.Automation.AutomationWorker, Sitecore.Analytics.Automation" singleInstance="true">
  <ThreadsCount>1</ThreadsCount>
  <Interval>00:00:10</Interval>
  <ContactRepository ref="contactRepository"/>
</automationWorker>

Make sure you haven't patched this value to use a longer interval.

Contact locking

Even though the automation worker runs every 10 seconds, it will only process automation states of unlocked contacts. This may become an issue if a user has a live session on your site—in that case, the corresponding contact's automation states will not be processed until the web session ends.

In your particular case, I suspect that a user's session ended and he started a new session with after a short pause of 1 minute or less. This means that, even though the contact was saved to the Collection database and may have been briefly unlocked, the automation worker didn't have a large enough time window to get an exclusive lock. As a result, the contact's engagement plan actions were executed with more than 20 minutes of delay.

Please also note that the contact will remain locked as long as there is at least one live web session of the contact, and then for one extra minute. xDB supports multiple simultaneous contact sessions.

https://doc.sitecore.net/sitecore_experience_platform/setting_up__maintaining/xdb/session_state/session_state#_Toc396298780

| improve this answer | |
  • Thank you for the very elaborate answer. It would be a great idea if Sitecore actually made these limitations very clear in the documentation for the engagement plans. – pwind Oct 14 '16 at 6:57
  • 1
    @pwind I couldn't agree more. – Dmytro Shevchenko Oct 14 '16 at 6:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.