Improve the handling of context album lookups in APEX-PDP task logic, especially for failure responses.

The response events coming to APEX from a system(example in AAI failure response) may not necessarily contain any field to tie it uniquely to the current control loop execution flow(e.g. requestId/eventId).

To understand the problem better, consider the below use case:

InputEventA1 is the trigger event triggering AxPolicyA. In the corresponding logic, the contextAlbum is populated with A1key(some relevant field from InputEventA1) as the key.

As per AxPolicyA, the other system(AAI) is hit over REST and the response(InputEventB1) is coming back to APEX-PDP, executing TaskLogicB. At this point, if the response event doesn’t contain the field which is used as the unique key in the contextAlbum(A1key), it is not possible to fetch the relevant details from the album specific to the event’s flow.

It would be good to have a solution to this, so that for every policy execution flow, there is some way to fetch data from the context album that is unique to the current flow.

Proposed Solution:

With some modifications, executionProperties can be utilized to save the contextAlbum key (or any relevant property) that is unique to execution flow of an event.

Currently, a new executionProperties object is created once the request/response flow in an AxPolicy is complete.

For example, in the above figure, ExecutionPropertiesA1, ExecutionPropertiesA2 and ExecutionPropertiesA3 are available in the AxPolicyA flow triggered by the corresponding events. After receiving the response, in AxPolicyB level, new executionProperties are created: ExecutionPropertiesB1, ExecutionPropertiesB2 and ExecutionPropertiesB3, and the old ones are lost.

The proposed solution is as below:

ExecutionProperties will be maintained per execution flow of an event. For example, ExecutionProperties1 will be available throughout the execution flow of the the event that triggered the policy: InputEventA1->OutputEventA1->InputEventB1->OutputEventB1

Similarly ExecutionProperties2 will be available throughout the flow: InputEventA2->OutputEventA2->InputEventB2->OutputEventB2

The contextAlbum key can be saved to the executionProperties,

For example,

“contextAlbumId”: “A1key” is saved to ExecutionProperties1

“contextAlbumId”: “A2key” is saved to ExecutionProperties2

“contextAlbumId”: “A3key” is saved to ExecutionProperties3.

In TaskLogicB, executor.getExecutionProperties().getProperty("contextAlbumId")) will return “A1key” if it is InputEvent1’s flow, “A2key” if it is InputEvent2’s flow and so on.

This way the required context album key can be obtained and contextAlbum lookup is straightaway possible to fetch the details relevant to the event.

  • No labels

5 Comments

  1. Aah OK, so you're using the event name as an index to find the key. What happens if two instances of InputEventB1 occur and occur out of sequence?

    1. Not eventName specifically, but eventId or requestId etc or any such field that maybe unique to the event can act as the key in the album, and executionProperties can be used as a place to save this key that is unique per execution flow of an event.

      2 instances of InputEventB1 will occur only if 2 instances of InputEventA1 triggered them. The entry in the album will be replaced if duplicate events are triggered with the same key being used. In such cases, if we still want unique entries in the album(depending on the usecase), then something like timestamp will have to go as the key, and still executionProperties can store it throughout the event flow

      1. I already did something similar to this in policies, I had a second context album for storing the keys, an example is the vCPE policy. The first context album has the data and the second context album is indexed by the return type of the "B" events above. Would that work?

        1. But if the response event (InputEventB1) doesn't have any useful information(or header fields - e.g. AAI failure response), how to fetch the correct entry from the album?

          1. OK, I get it now, you're copying the ExecutionProperties in the requestors, that's a great idea.