Michal's Tips: AIF 3.0 - Serialization - parallel processing

[MichalKrawczyk]

Sometimes we need to post a transaction which locks a certain object and other transactions using the same or other interfaces cannot get posted at the same time. What happens in that case is that interfaces fail and only the first one gets posted as shown in the figure below.

Then the interfaces which failed need to get restarted, either manually or in some cases we can restart them automatically.

AIF 3.0 (new version available as of October 2014) offers a new functionality which can help to solve such issues without the necessity of restarting the interfaces which failed. The new function is called - Serialization - Paralell Processing and in this article I will try to describe the steps required to customize this new function.

The idea behind this functionality is that we can use a predefined locking object which can tell AIF if the transaction is currently being locked and if such a situation happens, we can wait for a predefined amount of time, before we try to process the message so it will not fail with the locking error. We can add this functionality to any of your existing AIF interfaces suffering from the locking issues using just the customizing.

Step 1

At first we need to define the fields of the interface which can be assigned to the locking objects. With AIF we can do that by defining the Key Fields. In order to do that we need to create a new AIF index table with all fields which will be used by the lock object as per the figure below. In this case I’m using a flight demo scenario and I will have two locking fields (AIRLINE_ID and BOOKING_NUMBER).

Step 2

Then we need to define both of the Key Fields in the /AIF/CUST/ - Error Handling - Define Interface-Specific Features

Step 3

In the next step we can define a serialization object /AIF/CUST/ - Interface Development - Additional Interface Properties - Define Serialization Settings, where we can select the locking object and most important parameters like: wait time (time the AIF runtime needs to wait before processing the interface which was locked) and Max. No of Retries (self explanatory). In case of the flight booking scenario we can use the ESBOOK lock object as shown in the figure below.

Step 4

Once the lock object is assigned we need to assign it to the AIF interface and we can do that in the same menu as Step 3.

Step 5

The last customizing step is to assign the locking fields to the AIF Key Fields (defined in Step 2). The assignment is done on the basis of the locking object fields and Key Field sequence number.

Once all the settings are done we can try testing the new scenario and if we send multiple messages with the same lock key at the same time this time they should not fail but stay in the processing mode (till the wait time from Step 3 is reached) as shown in figure below.

Once the lock is free and assuming the Max. No of Retries parameter from Step 3 is not reached all of the interfaces should get posted without any issues as shown in figure below.

I hope that gives you an idea on how this type of AIF serialization is working. In the next articles I will try to describe other features of AIF serialization (external, internal indexes).