cancel
Showing results for 
Search instead for 
Did you mean: 

SAP MEINT message retry mechanism

Former Member
0 Kudos

Hi Experts,

I am stuck up with a MEINT message retry behavior in a client's production system.

If my understanding is right, messages in MEINT integration queue are retried only for connectivity failures during processing and not the data errors. Data errors have to be retried manually. Correct me if i am wrong.

If the above understanding is right, please help me on the following issues.

Prod system details

  1. MEINT is on 12.2.3 Build(182)
  2. Production order Messages to MEINT integration queue are posted directly from a custom MII application and not from ECC.
  3. retry limit is configured for each message.

Behaviour :

What i observed is that whenever the messages are queued into the integration queue, the attempts/retry limit column is displayed as 0/1 (this is OK) and then followed by 1/1 and sometimes even 2/1. When the processing is not complete and the status is queued how this can show 1/1 or 2/1?

At the end of message processing the result sometimes displayed as 2/1. this means the message is attempted twice right. or this has a different meaning?

Typically on every refresh of queue monitor for a production order message, we observed the following for some orders

Order in

Attempts/Retry limit                      Status

0/1                                              queued

1/1                                              queued

2/1                                              queued

2/1                                              success or failed

2/1                                              success if its failed previously

Is this behaviour right. and this is happening only for few orders typically in a particular timeframe where we also noticed that scheduler is in the running state for a long time. This behaviour is not consistent as well and happening randomly.

Also we noticed that the outbound messages like yield confirmations are automatically retried even for data related error and sometimes not and we have to retry it manually. can anyone throw light on the above two issues.

Thanks

Mahalakshmi Syamsunder.

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

To address why it retries sometimes and at other times requires manual retry, in the workflow there is a ResponseXSLT step.  You will need to create a custom XSLT to handle the errors you get back from ECC or the corresponding system.  If the error code is classified as a SYS_ERROR it will retry, if it classified as an APP_ERROR it will not.  The standard Response XSLT has an example for error code 469 or when the connection to ECC fails.  Any other error will result in SYS_ERROR thus no retry.

You can see the error code in the response XSLT in the Document Trace Response.

Does your code which inserts the transaction into SAPMEINT utilize the standard Enqueuer logic or is it custom?  If you do, you may have the retry limit hard coded rather than looking at the workflow to identify it as the standard Enqueuer does.  We had a similar issue utilizing a web service.

We also see the 2/1 sometimes if there is more than one dispatcher running or if there is still one running in the background which you can not see.  For example, if you stop the dispatcher mid-job it will continue running in the background until all of the records are processed and because there is no indicator in the MEINT database to identify whether a record is currently being processed if you restart the dispatcher it wil process the record again since the previous job has not updated it yet.

Former Member
0 Kudos

Hi,

Thanks for all your replies. I will suggest for a patch upgrade.

Thanks

S.Mahalakshmi

Answers (1)

Answers (1)

sergiy_katerinich
Active Contributor
0 Kudos

Hi!

In general, your understanding is correct.

But there are some questions:

1) is this about Standard Interface or High Performance?

2) what is the version of SAPMEINT and SAP ME?

3) I guess right now Retry Limit is set to 1. Does it make any difference if you set it to 3, for example?

4) is the timeframe between 1/1 and increase to 2/1 greater than SAPMEINT_RETRY_RETENTION_TERIOD?

5) if you turn off dispatcher job and execute it manually, how does the counter behave in this case?

Regards,

Sergiy

Former Member
0 Kudos

Hi Sergiy,

Thanks for your response.

Below are my replies.

1) is this about Standard Interface or High Performance?

Standard interface. Just to add an information - Standard inbound enqueuer scheduler is not in place as the custom MII solution does that job of processing the inbound idocs to MEINT integration queue thru web services.

2) what is the version of SAPMEINT and SAP ME?

MEINT :   12.2.3 Build(182)

ME      :   6.0.3

3) I guess right now Retry Limit is set to 1. Does it make any difference if you set it to 3, for example?

I could see that retry limit is set to 3 though its displaying as 1 in the queue monitor.

4) is the timeframe between 1/1 and increase to 2/1 greater than SAPMEINT_RETRY_RETENTION_TERIOD?

SAPMEINT_RETRY_RETENTION_PERIOD is set to 2 minutes. I am not sure on this timeframe though I believe it must be less than 2 mins.

5) if you turn off dispatcher job and execute it manually, how does the counter behave in this case?

Being a production system, I haven’t tried this. Also to add, this happens randomly and working fine otherwise.

Thanks

Mahalakshmi  Syamsunder

sergiy_katerinich
Active Contributor
0 Kudos

Hi!

6.0.3 is quite an old one - thus I would recommend that you upgrade at least to the latest patch of 6.0.4.

Regards,

Sergiy

sergiy_katerinich
Active Contributor
0 Kudos

And you also need to check if MII upgrade is needed for ME 6.0.4.

Former Member
0 Kudos

Hi sergiy,

Thanks for your reply and suggestion.

Have we faced similar behaviour/issues for this MEINT/ME version so that we can confirm the client to go with this decision.

Thanks

Mahalakshmi Syamsunder

sergiy_katerinich
Active Contributor
0 Kudos

Hi Mahalakshmi!

I have confirmed with MII expert that a mechanism of MII scheduler was re-written in some last SPs. You can check this by means of searching SAP Notes of MFG-MII* components. This could be the reason why the issue is not observed by other SAPME customers.

Regards,

Sergiy