SAPMEINT Parallel Processing

[Former Member]

Hello,

we have implemented the following note to have multiple queues for our messages.

http://service.sap.com/sap/support/notes/2000811

Currently we had queues for the orders and the material.

As we see performance problems and the possibility due to the fact that we split orders (into main and sub-orders) I defined the split process to dynamically name the new message type with a random value at the end.

E.g. LOIPRO03_1, LOIPRO03_2, LOIPRO03_3

For each of the types I created a workflow with a seperate PROC_TYPE to allow parallization.

Unfortunately now we receive problems with the default creation mechanism, because some objects in ME are interfering each other:

Record updated by another user (Message 10006) at com.sap.me.frame.BaseDAO.abort(BaseDAO.java:2636) at com.sap.me.frame.BasicBOBean.abort(BasicBOBean.java:2100) at com.sap.me.frame.BasicBOBean.dbUpdate(BasicBOBean.java:490) at com.sap.me.productdefinition.OperationBOBean.dbUpdate(OperationBOBean.java:147) at com.sap.me.frame.BasicBOBean.dbUpdateAndRead(BasicBOBean.java:605) at sun.reflect.GeneratedMethodAccessor13511.invoke(Unknown Source

Do you have an idea how we can have parallel processing for the same objects in ME? Like orders?

Regards,

Kai

[sergiy_katerinich · Accepted solution]

Hi Kai,

I guess (and your observations seem to confirm my opinion) it is a bad idea to split processing of the same IDoc into a parallel processing. It looks as if your parallel queues are processing the same object (operation/BOM/routing) which is referenced by different IDocs from different queues.

Originally, parallel processing was meant for splitting out a specific IDoc so the it is not sitting in the general queue among a lot of other IDoc types.

So, I really doubt your requirement is covered by the original design of the parallel processing.

Regards,

Sergiy

[sergiy_katerinich · Accepted solution]

In fact, your issue is related to right the following warning of the SAP Note:

"Note: Because most message types are dependent on other messages, SAPMEINT processes the messages sequencially in the order they arrive. Because of these possible dependencies, this feature should be used very carefully, otherwise this may cause data inconsistency issues."

Regards,

Sergiy

[Former Member · Accepted solution]

Hi Sergiy,

I have read the annotation but I thought this would be for the same order. Not for different orders which are relying on the same information.

Can we split the queues by plant? This would help in one scenario to have the orders processed by plant. Then ME would not look the objects because they are plant specific correct?

We currently have the scenario that due to calculations in ERP every morning a bunch of orders (hundreds) are sent to ME. This takes then a lot of time for processing in sequence.

This was my root problem where i thought I can optimize by using parellisation.

Regards,

Kai

[sergiy_katerinich · Accepted solution]

Kai,

I would say that splitting by plant might work once LOIPRO does not include any cross-database objects but only site-specific ones. So, you can give it a go.

Regards,

Sergiy

[Former Member · Accepted solution]

Hi Sergiy,

is there any future approach to have this possibility? Considering topics like big plants with high volumes of orders / big data?!?

Regards,

Kai

[sergiy_katerinich · Accepted solution]

Kai,

If you mean whether there is a further development of parallel processing in SAPMEINT, I have not heard about such tasks. I'll try to dig deeper, and if anything found, I will let you know.

Regards,

Sergiy

[sergiy_katerinich · Accepted solution]

Kai,

There is no plan of further development on this topic. The Note was meant to provide some possible approach to parallel processing in SAPMEINT rather than out-of-the-box solution. So, for now, each implementation of parallel processing is considered as a customer-specific project, usually carried out by customer's team, like a sort of customization.

Regards,

Sergiy

[alexander_teslyuk]

Hello Kai,

Is it a sporadic error that happens rarely or something that can be reproduced on demand once you define that split logic?

In case it can be reproduced on demand, I would suggest that you open a support incident to replicate the same on SAP side and investigate it deeper.

In case it is a sporadic error, a possible scenario can be:

1. Order is retrieved in SAP ME (i.e. in Shop Order Maintenance or maybe by some activity like Release) by MEuser.

2. Order is updated via MEINT by MESYS.

3. MEuser tries to save the Order.

In this case, please, make sure the Order is not processed nor updated in SAP ME in the meantime. Perhaps, setting on Hold in advance can help.

Adding additional Tracing in MII transactions can help to catch more details against what particular Orders were affected.

Br, Alex.

[Former Member]

Hi Alex,

it can be reproduced.

The scenario is the followin. We receive one IDOC from ERP with the information from one order. Based on its information we create one main and multiple sub-orders (with their own shop order number in ME) with the split logic. Thats not the problem yet.

With the split logic we create the new message types with a random value at the end E.g. LOIPRO03_1, LOIPRO03_2, LOIPRO03_3

These are now processed in parallel. The problem now occurs not on the order because each item has a different order number. The problem occurs on the operation. Because they can all use the operation coming from the base routing in ME. Therfore the operations object throws the DB Update error.

Regards,

Kai