cancel
Showing results for 
Search instead for 
Did you mean: 

SXMB_MONI shows messages older than the PERSIS_DURATION parameter

Former Member
0 Kudos

Hi All,

On our production system, we are not using archiving and, the PERSIST_DURATION for the deletion process is setup to 1. However, using the SXMB_MONI we can see messages even 13 day old.

Help would be really appreciated as I can't find the reason for this. The jobs are scheduled to run daily and the logs show that messages are being deleted. However, they do not follow the parameters.

Thanks in advance,

Encinas.

Accepted Solutions (0)

Answers (1)

Answers (1)

Former Member
0 Kudos

What status are they in ?

Thanks.

Former Member
0 Kudos

Hi,

The status is "Processed Successfully".

Thanks!

Former Member
0 Kudos

Have you check this note - 872388

this talks about troubleshooting/archiving of XI3.0 messages...

Thanks.

Former Member
0 Kudos

Yep, I read that but not really usefull. I'll read it again anyway.

Former Member
0 Kudos

The key there is to make sure the deletion jobs are running successfully...i would assume you have checked the status of the deletion jobs in SM37 for starters

Thanks.

Former Member
0 Kudos

Yes, they have all finished and the log shows how many have been deleted. And if the "Integration Engine: Job Overview" shows the deletion jobs in also in green.

Thanks.

Former Member
0 Kudos

Hi Esther,

Have you checked this point ...

*******************************************************************************************

Keep in mind that you may have activated the table switch procedure. You can check this via transaction sxmb_adm -> Configure delete procedure. The information button on that screen explains the switch procedure in detail. If the switch procedure is chosen, then the XML messages will only be removed (via table drop) if A) the retention time is expired and B) a specific fill grade of the table is reached. The default value is 90, that is the deletion will occur when 90% of the table is filled. You can set this parameter via transaction sxmb_adm -> Configure Integration Engine -> Specific Configuration. Create an entry of category DELETION, parameter DROP_MAX_TABLE_LOAD, no subparameter.

*******************************************************************************************

the messages are not deleted, but only marked as deleted if the switch procedure is activtaed...check in SXMB_ADM

Thanks.

Former Member
0 Kudos

Hi,

We do have that flag activated but, the documentation also says:

When the delete job is started, the table entries are not physically deleted from the database tables as in the procedure above; instead the Deleted flag is set in the master entry. The monitors then no longer display this XML message.

That's why I don't understand why they are still listed on the monitoring tool.

Thanks for your answer.

Former Member
0 Kudos

Hi all again,

I have checked the following:

Define Interfaces for Archiving and Retention Periods

-> Retention Period

-> History Entries for Deleted XML Messages = 10

As we do not use archiving, we have defined no interface for archiving. Does this parameter also affect all the messages? Anyway, the value for this is 10 and I can see successfully messages over 14 days.

Thanks and kind regards.

Former Member
0 Kudos

Hi Esther,

I think the best way to go forward would be to open an OSS message (if you have not done so already)...

Another point in the OSS note referred earlier...

*******************************************************************************

Check if there are message with a digital signature. These messages are archived by default. If you have defined no interfaces for archiving and have only set up the deletion procedure then these messages with a digital signature will not be removed from the database. Schedule archiving jobs to remove signed messages from the database. If you do not know if a digital signature is used for your messages, use transaction SE16 -> table SXMSPMAST (or SXMSPMAST2 if table switch is activated) and check for entries with value "1" in the field "SECURITY".

*******************************************************************************

Thanks.

Former Member
0 Kudos

Hi,

I think I found something that could explain my problem. All the messages that I can see thru SXMB_MONI are the ones that send IDOCS and, found this on help.sap:

SXMS_REFRESH_ADAPTER_STATUS -> This job checks the status of messages that were sent to the IDoc adapter. Since the IDoc adapter does not send response messages, it is not automatically known whether a message was processed or not.

I have checked that this job is not being scheduled on this system and so, all the idoc messages are kept in XI longer.

Could this explain this problem?

Thanks for your help!

Former Member
0 Kudos

HI,

No periodical tasks need to be scheduled for the System Landscape Directory, the Integration Builder, and the Adapter Engine of SAP Exchange Infrastructure (XI).

The following periodical tasks are recommended for the Integration Server/Engine of SAP XI

Between 1 hour and 1 day, depending on the intensity of the usage of the IDoc adapter

This job checks the status of messages that were sent to the IDoc adapter. Since the IDoc adapter does not send response messages, it is not automatically known whether a message was processed or not.

See more details from below link

http://help.sap.com/saphelp_nw04/helpdata/en/cd/20bc3ff6beeb0ce10000000a114084/frameset.htm

Regards

Chilla..

Former Member
0 Kudos

Hi Esther,

Did scheduling of this report solve the issue ? if that is the case,...great job...!

In our system deletion jobs are running smoothly and we have lot of IDoc scenarios....

We have the report SXMS_REFRESH_ADAPTER_STATUS scheduled to run every hour.

Thanks.

Former Member
0 Kudos

Well, I can't perform this on a productive environment right away but I hope it does!

Thanks!

Former Member
0 Kudos

Hi Esther,

if you just want to delete the messages go to SXMB_ADM and click on "Schedule delete job". That one will free you of all succesfully processed messages which are older than the retention time.

Regards

Cornelius