Delayed processing of AIF messages
Since support package 3 (AIF 3) or support package 10 (AIF 2) AIF provides a mechanism that allows taking control over the point in time in which messages are processed as well as the amount of messages that are processed. However there are limitations which will be explained in detail below.
To use this feature you need to maintain a Runtime Configuration Group (RCG) in Transaction /AIF/PERS_CGR.
In this RCG you need to specify a Namespace (NS) and a Runtime Config. ID (Name) by which the RCG will be identified later on.
It is vital to uncheck the „Runtime Cfg Active“-checkbox, as this will prevent the messages from being processed instantly as soon as they arrive. Finally you probably want to check the “Run Scheduled” and “Schedule Packages” checkboxes and specify how many messages you want to queue up and how big the packages should be that are processed per background job. This given example would queue up 200 messages and assign them to a run until it is marked “complete”. During processing of a run those 200 messages are split into 5 background jobs with 40 messages each. If you dont check the two checkboxes will be processed in the process of /AIF/PERS_RUN_EXECUTE rather than inside a background job.
Now you just have to specify the created RCG using its namespace and name while calling the /AIF/CL_ENABLER_XML class.
You should now see your incoming messages queue up in status “in process” in the AIF Error Monitor /AIF/ERR.
Once the configured amount of messages is available the run is considered complete and can be started using the report /AIF/PERS_RUN_EXECUTE
Here you need to specify the runtime configuration again and when you execute the report it will start all completed runs according to the runtime configuration. You probably already see that this is the cause for the limitations I mentioned in the beginning of this article. As long as the run is not completely full, no messages are processed. If there are several runs completed then all messages in those runs are processed. There currently is no way to limit the amount of runs that are processed. However there is a SAP-Note (Note Number 2215829 ) that covers the execution of incomplete runs to prevent messages from idling forever inside an incomplete run if no more messages are received.
David - thanks for the excellent write up. It's great to see we have the capability to queue these up before processing.
Also, are there any plans to have any sessions on AIF at TechEd?
Hello,
thanks for this nice new way of using runtime groups.
What I don't really understand is: where does the coding statement belong that you posted?
Regards Florian
Hi Florian,
The codeblock which calls the /aif/cl_enabler_xml is used to create a message in AIF. Depending on your scenario there could be various places for this call.
For example we have one call inside a couple of RFC Enabled Function Modules to allow several remote systems to create AIF Messages via HTTPS-Webservice.
Another Example would be a program, which instead of doing the work itself just creates an AIF Message and has AIF do the work in order to harvest its value mapping monitoring and restart capabilities.
Please refer to the AIF Cookbook for details or get back to me if you need further clarification.
Kind Regards
David
Hi David,
I think I do understand now, how it is used. Thanks a lot for taking your time for the explanation.
Regards
Florian
Hi David,
Thanks for the wonderful blog.
Could you please explain this - "Once the configured amount of messages is available the run is considered complete"
Does it mean that the run will change to status "Ready" automatically, once the configured amount of messages is reached?
Thanks in advance.
Regards,
Raja
Hi Raja,
thanks. Yes the run will be ready automatically and the program /AIF/PERS_RUN_EXECUTE will then find it and process all messages that are attached to it.
Regards
David
Hi David,
Thanks for the response.
For me, it was not changing to status "Ready" automatically, it always stayed in status "New" although messages per run reached its limit. The hint you gave in your blog about this note 2215829 and other notes - 2254516, 2207854 solved this issue. Thank you very much once again.
Regards,
Raja