Skip to main content

We have a set of businessrules which determine what type of time_commit to add to a task.

When the time_commit is added, the commit time is calculated based on a user_def field, which subtracts the field from the set task duration.

As per the documentation, the commit_dttm field can be changed, as we are trying to do via a businessrule.

Our issue is that the time_commit is automatically expiring on the original commit_dttm, and not the new commit_dttm.

The update on the task time commit is showing the new commit_dttm as expected.

XML used to update the time commit:

<time_commit>
    <tc_id>@tc_id</tc_id>
    <commit_dttm>@expressionsrequest_ext.required_end_date-Minutes(task.plan_task_dur_min)]</commit_dttm>
    <update />
</time_commit>

 

I’ve found some messages in the log indicating that SME is running expire on the time_commit, long before it should expire:

Timestamp: 2020-09-25T12:48:07.1243093+02:00
Message: SME SendNewMessageInbound msg.Id=6a4ded03-940b-4afc-bda9-bce02e818241\343575 msg.Label=Message Label Time commitment ID 69211 has expired. -Metrix Monitor Rule: sent@9/25/2020 12:48:07 PM execute@12/2/2020 3:20:00 PM
 

 

For the original time_commit we use response type ARRIVAL Commit Interval of ‘0’, and no Fulfill Event.

 

 

As stated in the documentation; 

If you want your time commitments to be automatically expired or fulfilled, you must specify a fulfill event on the response code.

 

I would expect that no time_commits are expired when no fulfill event is specified on the response code..

Reply


Terms & ConditionsCookie settings