Destination rule that checks for attachments on the parent event

Hi!

I tested this myself, and I took notice of a particular detail in the error:

There has been an integration error. A Destination contains an invalid filter. Destination: 'ETM TEST - Ad-hoc Tasks' with target: 'ETM_Ad-hoc Tasks Test'. Filter content: 'if ("NORMALTASK" = "NORMALTASK" and [] >= 0, true, false)'

This [] coincides with parentEvent in the message delivery expression, pointing to the parentEvent property being evaluated as null. This will be the case if you’re creating an Ad-hoc Task, which unlike tasks created from workflows, do not not populate the parentEvent property.

IFS Assyst Wiki: Ad-hoc Tasks:

... Note: The Create Task Event option does not create a parent/child relationship between the created Task and the Event it is created from. As the ad-hoc task function does not set the parent ID field on the Task, no value is shown in the Task Parent Monitor Column for ad hoc tasks.

I might be wrong, but I dont think there is a way to get the source event directly from a task when the task is created as an ad-hoc task. 

Some ideas for how to approach:

You could try to get to the source event through a delivery expression by “stepping through” the newly created task’s linkedEventGroup → linkedEvents → linkedEvent etc. chain.

I haven’t tested making such a deliver expression myself, but during task creation, the automatic link to the source event is added by the system before the destination evaluates the new task. As this auto-link seems to reliably exist during evaluation, you should be able to get the parent event and evaluate whether an attachment exists.

This approach also assumes that multi-step evaluations “quit early” if the start of the delivery expression is not responsive, to avoid impacting general performance. This concern seems unwarranted, as the expression you’ve provided did not cause any errors when logging other types of events with this destination active. (I would assume that if the entire expression were evaluated, then other event types would also trigger the same error during logging.)

Alternative approach:

Use ETM to log the ad-hoc tasks based on an action as input, rather than using the Event Monitor → Create Task method. This could act as an easier way for users to create tasks, as when an action is used as the input, you have a direct link to the source event and can easily evaluate the existence of an attachment in the destination delivery expression.

The tricky part with this approach is that you need to manually create the event link between the source event and the task using ETM. You also lose lookup selectors in the Create Task popup, so allowing users to select which service department the newly created event will appear in won’t be possible. Additionally, you lose access to the “Go to Task Form” for filling out a more detailed task.

Third approach (with mixed feelings):

Let ETM handle all the filtering and forego using the destination to check whether the source event has an attachment. This is probably the easiest to implement and lets users keep the regular GUI for creating tasks. However, it has the drawback of “spamming” ETM with needless “success” imports in the ETM imports log even when an import is filtered by the filtering expression. I also haven’t been able to estimate if this is more or less scalable than the other methods. 

Either way, this sort of ETM filtering can be done by first setting the event destination Message Delivery Expression to:

if ($new.eventTypeEnum = "NORMALTASK", true, false)

…and adding some additional data to the message body by setting the destination’s Message Filtering and Expansion to something like this:

[linkedEventGroups.linkedEvents.linkedEvent.[attachments]]

This extra data will become part of the eventual inbound which helps reduce the overall load on the application by preventing ETM from needing to make a separate REST lookup to get info from the source event.

The ETM channel can then be set up to listen to this destination, and using a filter expression on the data mapper(s), you can stop the channel from any unnecessary further processing if the “source event” does not have at least one attachment.

I’ve made a proof of concept filter expression for this last aproach, but not thoulgly tested it yet: 

(function(inbound) {
  try {
    var groups = inbound && inbound.linkedEventGroups;
    if (!groups || !groups.length) return false;

    var events = groups[0].linkedEvents;
    if (!events || !events.length) return false;

    for (var i = 0; i < events.length; i++) {
      var le = events[i];
      var linkedEvent = le && le.linkedEvent;
      if (!linkedEvent || linkedEvent.id === inbound.id) continue;

      var attachments = linkedEvent.attachments;
      if (attachments && attachments.length >= 1) {
        return true;
      }
    }

    return false;
  } catch (e) {
    return false;
  }
})(inbound)

All that said, it would be very nice if there were a more direct way to link an ad-hoc task to its source event without having to rely on these kinds of workarounds to get the desired behavior 😅

I very much welcome it if anyone else has ideas or a more elegant way to solve this 

Best regards,

Richard

Thank you for the reply, however this is not in any way related to ad-hoc tasks. We do not use ad-hoc tasks in our environment, this issue is occurring with normal tasks which are created from workflow. 

I have no issue doing what i want to with the ETM channel / mapper if I send the ID of the task to ETM every time a normal task is created, but since that would result in a high number of destination messages going to ETM which don’t result in any update, I’d rather evaluate if any attachments exist on the parent before sending the message to ETM, as part of the rule. 

I will try a few more things and update any progress here. 

Duncan

Hello Duncan,

Since you configured destination on “create” only I assume that you do not want to trigger the ETM if a user added an attachment to an existing event. If not, I suggest using “update” on the destination as well.

When you are using “totalAttachmentCount” it will return the attachments in the event and the attachments in that event’s action as well.

I am not sure why you are using “event type Enum” in the condition. Correct me If I understand your requirement wrong.

My suggestion is to set the destination entity to “event” then use the following expression and check whether it returns proper results.

$new.totalAttachmentCount >= 0

* You do not need word ‘event’ after $new, assyst will pick that from the entity. No might not need for true or false values either. So, this expression will evaluate to true when a user creates a parent event with attachments. When the assyst is creating a task there will be no attachments, attachments come to task after the creation. So this should work.

Let us know how it went. If this did not work, I suggest logging an incident with axios.support@ifs.com so we can check this with the dev team as well.!--startfragment>