Define interface for archiving not working for specified inbound interface

[Former Member]

Hi @ll,

at the moment I´m reorganizing our list of interfaces which should be archived.

Because in some cases we don´t want to archive all messages of a particular outbound interface e.g. ORDERS05 idoc, I thought to use the the inbound interface (receiver interface) to differ between messages which should be archived and messages which should be deleted.

Therefore I added the inbound interface of the messages which should be archived to the archive list (sxmb_adm).

After testing this configuration messages which have this inbound interface are marked for deletion and not for archiving in table SXMSPMAST.

Looking at the trace of the pipeline step Inbound Message, there is the entry --no interface action for sender or receiver found Hence set action to DEL

When I look at the trace of a message which is flagged to be archived, there is the entry found interface XYZ, found action ARCH

It seems that the decision whether to archive or not is made quite early during the processing of the message. At this time the receiver and interface determination not yet done.

Is it not possible to use the receiver interface for definition of archive messages?

Are there other possibilities for defining archive messages depending on the receiver interface?

Any help appreciated.

Thanks in advance

Kind regards

Jochen

[former_member334189]

Dear Jochen,

you want to know all the details, don't you? Actually you are the very first person asking how the receiver information can be evaluated right in the inbound handler, ie. when interface/receiver has not been carried out.

The trick is pretty simple and there is no magic behind: we do the interface check twice. The first check is done during the in inbound handler of the core engine. The result is what you see in the inbound version of the message. The second check is carried out right when interface/receiver determination has completed.

In SXMB_ITFACTION you maintain a set of rules. If any of the rules matches, the message is flagged for archving, however, there is no prioritization or combination of rules (like if OB=X AND IB=Y THEN archive). In other words: whenever a sender interface or receiver interface of a message is found in the list, the message is to be archived.

There is a known issue with evaluation of these rules. This has been reported as Hot News and issue was fixed by SAP Note 1131367.

In case that note does not solve your issue we should have a look into this directly. Kindly open an OSS ticket with reference to this thread and send it to BC-XI-IS-IEN. We will then need R/3 access as well as one sample message ID. If it is an productive system please set the priority of the ticket to HIGH.

Best regards,

Harald Keimer

XI Development Support

SAP AG, Walldorf

[Former Member]

Hi Harald,

thank you for your reply.

It is good to hear that there are possibilities to define rules depending on the inbound interface.

The note you mentioned doesn´t meet our release and could not be implemented.

After your reply I created a sample scenario and made some tests on our development system.

I defined a rule for an inbound interface to be archived.

Afterwards I sent a message via proxy from the SAP backend and from the HTTP test formular available in the runtime workbench. In both cases the message is flagged to be archived, which is correct.

Afterwards I defined a sample ftp adapter and run this scenario again (all the interface are the same). And in this case the message is not flagged to be archived.

Furthermore I created also a sender SOAP channel and send the message over this channel to PI and in this case the flag was correct again.

Do have any reason for this behaviour?

My colleague from SAP Basis is on vacation this week, when he is back I will run some test via IDoc adapter on our quality environment and also repeat the test mentioned above.

In some threads I read about a possibilty to decide whether to archive only the source version of an incoming message or all versions created during runtime processing.

I didn´t find an option in sxmb_itfaction to specify this. Do you have any suggestions on this, too?

Kind regards

Jochen

[former_member334189]

Dear Jochen,

yes, I can help you on both issues.

Thanks for taking the trouble to configure different scenarios. The information on messages sent by AdapterEngine(AE) is very valuable for me. This is because we identified an issue with this kind of messages a couple of weeks ago. The main issue here is that receiver information is added to the main header object of the message by the AE. These fields are empty, however, this does not matter; as the fields exist in the message they are taken into account during first interface check.

Please apply SAP Note 1448809 to the system. This shall finally fix the issue.

Regarding the restiction of archivng to the first version: from your reply posted on May 18th I knew that you are running on 7.00 or higher (rather than on 6.40). From your last reply I understand that you are on 7.10 or 7.11. In these releases archiving of first version only is not possible any longer.

The technical background for this is the activation of a new feature called Payload References. With this new internal feature a payload will be stored to database if and only if it has changed since the last time it was saved. Consequently we expect a maximum of 2 versions (before / after mapping service) such that we do not need to restrict archiving to the first version anymore.

Best regards,

Harald Keimer

XI Development Support

[Former Member]

Dear Harald,

thank you for your valuable tips.

Sorry that I didn´t answer for such a long time.

Today I had some space to come back to this topic and repeat the described tests with the File, SOAP and HTTP Formular.

As mentioned above I also made test with the IDoc sender adapter, because this is used for many interfaces.

After applying SAP note 1448809 the File and SOAP adapter worked fine and the test specifying a archiving rule for an inbound interface were successful.

But with the IDoc adapter the test was not successful. The message was flag to be deleted instead of to be archived.

When testing the same payload via HTTP test formular available in the runtime workbench the message is handled correctly.

Have you came across to this issue so far?

Kind regards

Jochen

[former_member334189]

Dear Jochen,

great to hear that I was able to help you with the AE scenarios!

I never observed such an issue for the IDoc adapter. I checked the recent changes done to the methods for determining the interface action, but none of them is applicable here.

My gut feeling is that this exceeds the scope of this forum. Most-likely we need R/3 access to the system under investigaton to help you with this issue. In addition it would be useful to see a sample message that was processed having LOGGING turned on (for all pipeline services) and TRACE_LEVEL set to 3.

Best regards,

Harald

[Former Member]

>

> In case that note does not solve your issue we should have a look into this directly. Kindly open an OSS ticket with reference to this thread and send it to BC-XI-IS-IEN. We will then need R/3 access as well as one sample message ID. If it is an productive system please set the priority of the ticket to HIGH.
> 

Hi Harald,

thank you for checking if there are known problems concerning the IDoc adapter.

As I understand you wright I should open an OSS in category BC-XI-IS-IEN for this issue and reference this thread.

I will do so this afternoon, hopefully SAP could bring in some light.

thanks for your support

Kind regards

Jochen

[former_member181962]

Hi,

Did you try giving both the the sender interface and the receiver interface simultaneously in SXMB_ADM->Define Interfaces for Archiving and Retention?

In other words, if you have Outbound interafce OB1 and two inbound interfaces IB1 and IB2.

Say you want to archive only the messages that go to IB1.

Then you have to go to SXMB_ADM ->Define Interfaces for Archiving and Retention and give the outbound interface as OB1 and Inbound interface as IB1.

http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/402fae48-0601-0010-3088-85c46a236... (Page 12)

Regards,

Ravi

[Former Member]

Hi Ravi,

thanks for your answer.

> Say you want to archive only the messages that go to IB1.

That´s just behaviour I want to ensure. I tried your suggestions enter both outbound and inbound interface name.

At first glance it seemed that the outbound interface has been also registered for archiving.

But when I have a look at the table SXMSARCITF2 there was only an entry for the inbound interface available.

And if I leave the transaction SXMB_ITFACTION and reopened it again the outbound interface wasn´t present in the overview table no longer.

To me this kind of defining archive interfaces seems not be able to define/handle conditions like when outbound interface OB1 and inound interface IB1 than archive, otherwise not

Such a condition is what I´m looking for.

An alternative for my needs would be if it will be possible to use only the inbound interface information for the decision to archive or not. But as I wrote in my initial post, the system seems not to care or know about the inbound interface when to decide to archive or not.

Do you think I´m wright?

Kind regards

Jochen