New SAP Press book (E-bite series): Serializing Interfaces in SAP AIF
As of AIF 3.0 a new, fantastic feature has been introduced – AIF serialization. Together with my two colleagues from Int4 – Michal Michalski and Krzysztof Luka we’ve decided to describe how do different options of AIF serialization work as we believe it’s usage can be a vital part of almost every AIF implementation due to it’s unique benefits.
SAP Press has published our book with it’s new format – E-bite. E-bites are supposed to be smaller books available only in electronic format and they need to concentrate on a single topic only – in our case serialization. Our book contains step-by-step instructions and screenshots that will enable you to explore your serialization options in SAP Application Integration Framework in no time, starting from the configuration up to monitoring and troubleshooting of the AIF serialization.
Where to buy:
SAP Press – Serializing Interfaces with SAP AIF
Reference:
My first book on AIF topic for business users – SOA Integration – Enterprise Service Monitoring (LIE, FEH/ECH, AIF)
Thank you Michal for sharing, looking forward to buy a copy.
Thanks
Agasthuri
Hi Michal,
bought this e-bite and on the way of running end-to-end scenario on our AIF 3.0 sandbox.
Have some comments:
On page 12 (of PDF version) custom index table is created and then is required to be linked to interface via "Define Interface-Specific Features". But this step fails, cause at this time there's no required record in /AIF/T_INF_TBL which is used as a filter on launch of this transaction.
I believe on Figure 5 you show "Define Namespace-Specific Features" (not *interface*) screen and there is an error in text before this figure.
Please, correct.
Regards,
Petr
Hi Petr,
You're right -
instead of :
Now we need to assign this index table to our interface under /AIF/CUST Error Handling Define Interface-Specific Features.
it should be:
"
Now we need to assign this index table to our interface under /AIF/CUST Error Handling Define Namespace-Specific Features. "
then the rest should work correctly,
Thank you for the comment !
Best Regards,
Michal
Hi Michal,
I have some more minor comments/corrections for the e-bite. Don't want to spam this here. Can you send me direct message via SDN and I will send all at once in reply? SDN does not allow me sending you such while we are "not friends".
Regards,
Petr
Thank you very much for spotting this Petr.
SAP Press production is already working on the correction which should be published in no time ( one of the benefits of the e-bite program ).
Thanks again.
Best regards,
Michal
Cool!
Like e-bites. 🙂
Hope you can help with the next issues I faced. Figure 25 says I have to receive message in /AIF/ERR that second message in sequence is not processed due to existing predecessor, which is halted due to error in it.
For first message in queue I receive the following messages:
This is Ok.
But for the second message (with Manual restart status) I can see no any log messages in the /AIF/ERR. And when I click on it system says:
Can you help with this? Am I missing smth?
Regards,
Petr
Hi Petr,
We will be happy to help.
Would it be possible for you to send us a screenshot from /AIF/ERR and the contents of your serialization table?
Many thanks.
Best regards,
Kris
Hi Krzysztof,
here they are:
I have a doubt regarding Figure 13 of the e-bite. Is it correct that MSGGUID must be a part of the key? Can't it cause the above problem?
Hi Petr,
Thanks for the screenshots. It looks like the serialization actually worked properly. The entries in your serialization table confirm that. Also the second message has been put on hold, which would not be the case without serialization.
As for your other question about the MSGUID, I can confirm that it is a correct setting. Otherwise, both messages (the one with error and one put on hold) could not be stored in the serialization table together.
I assume that the problem might be with the logging rather than serialization. By default AIF is using Trace level 0, which is the lowest trace level of the available (0 to 3). Could you check in /AIF/CUST->Error Handling->Define Global Features->Define Trace Level, what are the settings for the trace at level 0?
Please especially look at the setting for category "Others". Is any error category checked there?
Thanks.
Kris
Hi Krzysztof,
checked what you recommended.
Both "From framework" and "From individual interface" subareas have same flags.
"A" and "E" are marked for all rows (including "Others").
Additionally "I", "W" and "S" are marked only for "Function errors" row.
Tried to change settings of trace level for my interface by adding specific setting to /AIF/FINF_TL table. The number of log messages for first message with incorrect data increased and now I see more information rows. So this setting works. But with second message (which is halted) nothing changed. Still "No log found...".
Any ideas?
Regards,
Petr Perstnev
Hi Petr,
Can you check one more thing? In your index table, for the message that is put on hold, there should be an application log number entered in the field <your_index_table>-LOGNUMBER. If you find a log number there, could you go to ARAL, and see if you find any entries for log object /AIF/LOG and this log number ?
Thanks.
Regards,
Krzysztof
Hi Krzysztof,
that's what I see in index table...
and in ARAL ...
So, nothing was recorded for *824 in Log. Seems I have to dive in debugger. 🙂
Regards,
Petr
Ok. I found the reason why the messages are not stored in log.
After two messages are sent from AIF test tool, I can see the following in SM37.
Two first rows appear after first message. Next two - after message that is halted.
The one row that is red states, that execution caused a DUMP.
In DUMP there's the following:
Termination occurred in the ABAP program "SAPLSBAL_DB_INTERNAL" - in "BAL_INTERNAL_LOCK_ON_SAVE". The main program was "/AIF/PERS_RUN_PACK_EXECUTE ". In the source code you have the termination point in line 64 of the (Include) program "LSBAL_DB_INTERNALU07". The program "SAPLSBAL_DB_INTERNAL" was started as a background job. Job Name....... "/AIF/RUN_0000000091_PACK_00001"
And while it dumps, it can't write anything to the log. So at least this is now clear.
But can you imagine why it can dump here? Can't find anything useful to the case in SAPNOTES. Also, I can't debug it, cause break-points set in this FM are not working when this AIF processing task is launched in background.
Regards,
Petr
Hi Petr,
Thanks for the details. I did some research and found the following:
Getting Short Dumps for only 1 user - related t... | SCN
It is the same dump in a similar place, also occuring in AIF.
According to this, it might be an issue with authorisation. Since the jobs that you listed are processed on your user, can you make sure you have all the authorisations (e.g. reprocess both messages and then go to SU53 to check if anything is missing) ?
Also kindly check if you have role /AIF/ALL assigned.
Thanks.
Regards,
Kris
Hi Krzysztof,
I have /AIF/ALL auths. But in that case it was not a security issue, but problems in SAP standard code. We had AIF 702 w/o service packs on sandbox.
Asked basis mate to install SP1 for AIF 702 (just in case). And this solved above issue. After restart of the same message its feedback was correctly stored in BAL and now is visible in AIF just as you explain in e-bite.
Btw, maybe it is worth mentioning in the e-bite the versions of ABAP components you use in your examples just to cover such situations.
Thanks for your support and help nevertheless!!!
Best regards,
Petr
Hi Petr,
Please send you comments to sap.integration(at)gmail.com
Thank you,
Best Regards,
Michal
Hi Michal!
We now have serialization running for two of our interfaces (thanks to your e-bite). 🙂
But I have 2 questions regarding this functionality which we can't sort out.
1) We tried to combine for one interface [Serialization via External Timestamp] with [No-Serialization Serialization] (so our messages come in correct order and at the same time, locking is controlled).To accomplish this task, two serialization objects were created (one of each type) and our ORDER interface was included in each of them. But the results are not good.
As you can see, 1st message was processed, 2nd was put on hold due to locking issues, but this didn't stop 3rd from being processed.
Can you recommend solution for this?
2) We linked two interfaces/message types (ORDER and BILLING) to one serialization object so they are processed in correct sequence. So if ORDER message is stopped due to some errors, than BILLING is also stopped and waits for error correction. This is good. Now ORDER messages are automatically reprocessed by serialization engine one by one when if error in first of them is corrected and it is restarted. But messages in BILLING are not reprocessed and have to be "pushed" manually.
Is it so "by design" or we are missing smth?
Can reprocessing of all messages of different types included in one serialization object be triggered automatically?
Regards,
Petr Perstnev
Hi Petr,
1. First of all thank you for your comments ! Very valueable and most of them already included in the updated e-bite 🙂
2. For your issues with many message type - AFAIK this should work exactly as you're trying to use it so if it's not it might be a bug - did you raise an OSS message for both issues already ? If not please put in the same description and create one.
Thank you once more and I'm happy some parts are already working! 🙂
Best Regards,
Michal Krawczyk
Hi Michael Krawcyk,
can you please have a look to my question, which is about your Ebook? 🙂
AIF Error Monitor - don't display log messages
Thanks a lot and best Regards,
Paul Socke