cancel
Showing results for 
Search instead for 
Did you mean: 

PI 7.1 Archiving - Delete

Former Member
0 Kudos

hi Team,

We have PI 7.1 production environment and planning to implement ARCHIVING & DELETE for Integration Engine, Adapter Engine and Business Process Engine based messages.

I had referred to 'How to arhive & delete' doc that highly available in SDN but few question after going through the doc.

1. If a interface flagged for ARCHIVING then all messages in complete message status gets automatically Archived

2. And if interface not flagged for ARCHIVING then all messages of those interfaces gets automatically Deleted

Ofcourse on these both the cases, the corresponding action takes place only provided the retention period candition meets.

1. But Wondering, How about the messages that NOT successfully processed? Somewhere in SDN i red the NOT completetly proccessed messages require to be first 'Cancelled' and then they get marked for ARCH so that it gets archived! So in this case, both 'Synchronous" and "Asynchronous" not completely proccessed messages have to be marked for 'Cancel' before they get Archived?

2. Keeping this aside how the not completely processed archving, Why we need to archive the messages that are not completely proccessed in PRODUCTION environment?

3. In regards to 'NOT Completely processed' messages, I agree to certain extend that "All these have to be removed" from Database so that we gain disk space that helps improve the performance also? Please share your knowledge.

4. Either Archiving or Delete mechanism has any dependance or functional variations on Synchronous and Asysnchronous?

I highly appriciate all those add their knowledge here to clarify

Regards

Sekhar

Accepted Solutions (0)

Answers (2)

Answers (2)

former_member334189
Active Participant
0 Kudos

4. Either Archiving or Delete mechanism has any dependance or functional variations on Synchronous and Asysnchronous?

Well, yes: synchronous messages will never be archived. This is by design, see question 1.

Contrary, deletion does not take care of the processing mode (synchronous/asynchronous), except applying different retention periods to each kind of message (see transaction SXMB_ITFACTION).

Best regards,

Harald Keimer

XI Development Support

SAP AG, Walldorf

Former Member
0 Kudos

Hi Harald Keimer,

Thanks for detailed explanation.

I have few more follow up question to understand better.

1. It's clear now that, Interfaces set to 'ARCH' gets archived (provided they are processed successfully) and flagged to 'DEL/INIT' gets deleted automatically. And I also understood that, the error/failed messages have to be first 'CACELLED' so that they can be archived. But the queriy is - If there are bulk of 'error/failled' messages how do i go about changing these messages status to cancel status so that the subsequent Archive jobs will take care of them?

2. What's the best practice - Is there a job/report that can change these failed/error message status to 'cancel'?

3. a) With specific to Integration Engine messages, what are all different status of the messages?

b) Irrespective of whatever may be the message status, the answer of Question 2 will helps to make the messages cancel?

Appreciate your valuable answers.

Regards

Sekhar

former_member334189
Active Participant
0 Kudos

Dear Sekhar,

to my point of view all questions can be answered by one note. Please have a look at SAP Note 872388 and focus on section 5 paragraph k - 1). Here report RSXMB_CANCEL_MESSAGES is the tool of choice for mass data handling, i.e. for canceling a large set of messages. This report handles message that already are in error state. The message states handled by the report are listed in that note.

Furthermore this note points to table SXMSMSTAT to display all possible message states. These message states are used by the IS/IE internally for message processing. Thus, the content of that table provides an insight on the set of states that currently is used by PI. Please note that SAP does not gurantee that message states in that table remain unchanged; i.e. the table is subject to change at any time and without prior notice.

One more remark on canceling a set of messages: as an alternative to report RSXMB_CANCEL_MESSAGES you might also want to select a set of messages in SXMB_MONI and then cancel them by pressing button "Cancel Processing of Messages With Error" (CTRL+F8).

Best regards,

Harald Keimer

Former Member
0 Kudos

Thanks Harald Keimer.

For clarifying these items, I just want to understand the below items

1. I knew that RSXMB_SHOW_STATUS report gives me the current status overview of XML messages in the PMAST table but wondering how this report is different from RSXMB_SHOW_REORG_STATUS. When we use each of these reports?

2. From note# 872388 i red that If there are AFW based interfaces NOT marked for Archiving then per default XML messages gets deleted after 30 days, Just want to understand what/where the setting that's taking this action or is there any house keeping job that cleans up these messages after 30 days?

Thanks

Sekhar

Former Member
0 Kudos

Hi experts,

I have a double abort how archive works.

In out company, we don't want to archive any message. We have configure IE for retention period = 7 days. And the delete jobs are running correctly.

The problem is that we donu2019t have configured the archiving and if some error asynchronous message is cancelled the state change to ARCH (We can see that the field ITFACTION from SXMSPMAST table is set to ARCH).

Is mandatory to configure the archiving message to the file system?

And other issue is that we have 18.000 message with the field ITFACTION = INIT from SXMSPMAST table that are not in retention period.

If we analyses some message, there are in successful state but where proceeded in 2006!! Can someone explain how we can delete this message?

Thanks,

Albert

Former Member
0 Kudos

Hi Albert,

You need to configure report RSXMB_DELETE_ARCHIVED_MESSAGES to delete messages marked for ARCH.

Please go through my Wiki that elaborates the concept.

http://wiki.sdn.sap.com/wiki/pages/viewpage.action?pageId=147266890

Regards

Sekhar

former_member334189
Active Participant
0 Kudos

Dear Albert,

let me go through your questions step by step.

Per archiving: Once the Integration Server accepts an asynchronous message it takes over responsibility and it also ensures delivery according to the EO/EOIO protocol. In case a message is canceled this means a fatal violation of the delivery guarantee given to the sender of this message. Because of this the message must be archived in productive systems at any rate. There is no alternative (see also my explanation given to Sekhar on Oct 14).

In non-productive systems archiving can be omitted by using setting parameter ARCHIVE - PERSIST_ARCH_MANUAL_CHANGES (transaction SXMB_ADMIN -> Configure Integration Engine).

Per deletion: A message in PI is deleted if all of the following conditions hold

(1) retention period has expired

(2) message state is final

(3) adapter state is final

As you have stated that conditions (1) and (2) hold, the reason for not deleting these 18,000 messages most-likely is an inappropriate adapter state.

Please walk through SAP Note 872388 and focus on section 5 reading "Troubleshooting Archiving / Deletion of XML messages and history entries in the Integration Server...".

Best regards,

Harald Keimer

XI Development Support

SAP AG, Walldorf

Former Member
0 Kudos

Hi Harald

Thank you very much for your answer, the issue has been solved. The problem was that we didnu2019t have scheduled the report SXMS_REFRESH_ADAPTER_STATUS.

Now the report RSXMB_SHOW_REORG_STATUS shows

Number of messages in DB: 49.327

Number of messages in client: 49.327

Number of messages in client still to be reorganized: 2.653

thanks

Albert

former_member334189
Active Participant
0 Kudos

Dear Sekhar,

let me go through your questions step by step...

1. But Wondering, How about the messages that NOT successfully processed? Somewhere in SDN i red the NOT completetly proccessed messages require to be first 'Cancelled' and then they get marked for ARCH so that it gets archived! So in this case, both 'Synchronous" and "Asynchronous" not completely proccessed messages have to be marked for 'Cancel' before they get Archived?

This is almost correct. Canceling is required for asynchonous messages in error state only. By canceling a message its state changes from error to final and this it is allowed to be archived. In contrast synchronous messages are final right when processing fails.

Please note: archiving applies to asynchronous messages only. It is a general decision by SAP to not archive synchronous messages.

2. Keeping this aside how the not completely processed archving, Why we need to archive the messages that are not completely proccessed in PRODUCTION environment?

Once an asynchronous message enters the central Intergation Server(IS) or the local Integration Engine(IE) XI/PI takes over responsibility for this message. Canceling a message means a serious violation of the EO/EOIO protocol. This violation needs to be documented in productive environments for the purpose of tracebility.

3. In regards to 'NOT Completely processed' messages, I agree to certain extend that "All these have to be removed" from Database so that we gain disk space that helps improve the performance also? Please share your knowledge.

I am not quite sure that I got the point. For each message entering the IS/IE SAP has to provide a guided procedure to reorganize this message. For successfully processed messages this is done by standard house-keeping jobs for archivng and deletion. For messages in error state there are basically two ooptions:

(1) restert message after error has been fixed;

- if message processing is sucessful this time, we are back to normal

- if message processing fails again, we are in the very same siutation as before

(2) cancel messages; this males the message 'final' and then it is treated like sucessfully processed messages.

Thus, this is all about defining an end point in the lifecycle of each message.