RFCs sequence from MII to ERP

[Former Member]

Hi!

MII 12.1.7

Inside one transaction there are 3 JCo Functions, calling SAP native BAPIs, following strictly each other:

1. Consumption of material by the Production Order

2. Material issue from the Production Order

3. Confirmation of the Production Order

Each call have the same schema: Start Session - Function - Commit - End Session. The properties of Function and Session actions are default (RFC Type = Best Effort, Processing Type = Synchronous Processing, Pool Connections = true)

When MII makes Confirmation BAPI call it returns error that order is processed by MII user, despite that previous BAPI call was succesfull and returned correct data. The same error occurs if I try to put all Functions inside one Session block.

Another case: when first BAPI creates Planeed Order and second creates Production Order from planned one - second BAPI says that planned order ###, that was returned by first BAPI, does not exist.

I solved this problem only by putting Pause action between these calls, but I hope there is some better way to deal with this problem. Is there?

Is there any way to force next BAPI to "wait" untill data modified by previous BAPI will become actual in ERP and not blocked by MII itself? Can it be managed with Function and Session properties?

Thanks!

Best Regards

Petr

[Former Member]

3 points that could help here-

1) To reduce locks in Material Movements-

Try testing with transaction OMJI (test with 'Late exclusive lock'

settings)

"

Notes 70865 and 322989 contain interesting information on locks in

MM-IM. Transaction OMJI allow to set a late exclusive lock in order

to reduce the time that the material master data is locked.

"

2)

You could also automate the goods movements and post

Everything you are doing here with the confirmation posting via

backflush and auto Goods receipt.

When goods movements are posted linked with a confirmation they are what

We Call de-coupled. This means they get posted seperately to the confirmation

In the update task, Note 208477 explains this about the decoupled process.

It is very common to get locks during goods movement processing and the error

Handling of confirmation handles this eliminating the need for any manual

processing, a regularly scheduled run of the program

CORUPROC clears up any errors that arose out of lock situations.

There is settings for when the movements are updated set in the process control

Assigned to the confirmation parameters in transaction OPK4, the definition on the

Type of processing is transaction OPKC however these have no effect with bapi

Postings (back to note 208477)

Also different processes such as batch determination,classification and derivation

can slow down GM postings, if the runtime due to these occuring during GM posting

is an issue try to perform it in the order (see production schediling profile OPKP/CORY)

3)

Use the wait parameter in the commit bapi BAPI_TRANSACTION_COMMIT

and ensure to commit after each bapi call.

Kind Regards

Eoin

[Former Member]

Try doing everything in one call

[Former Member]

Christian, You mean to make ZBAPI which combines all these activities and call it? That can be an option, but it would be better to use native SAP BAPIs. And I hope there is a way to do this without programming.

[agentry_src]

Hi Petr,

If I understand your sequence properly, you do all three BAPIs first as you describe. Then you try to check Confirmation using another BAPI and that is when you recieve an error.

Please check with your Basis resources, but confirmations are saved when recieved by ECC, queued up, and then finish their processing sometime after MII has recieved the message that the Confirmation was saved. So what you may be seeing is some lag time between ECC recieving the Confirmation request and the completion of the processing. The Pauses that you put in are probably covering the required time from Saving the confirmation and when it finishes processing. The lag time can be from normally under 60 seconds to as bad as 30 minutes (in my experience). Your Basis folks can probably determine whether there is a way to force the completion of the confirmation as fast as possible depending upon system load.

While I am not a PP or PPPI expert, I have run into this issue quite a few times over my time working with MII. There are a number of postings on this forum, if you search back further than the default 90 days. There may be some other suggestions which you might find helpful in the other postings.

I have not done the planned order then the production order, but I would imagine it has a similar processing path.

Regards,

Mike

Edited by: Michael Appleby on Apr 6, 2011 3:31 PM

[Former Member]

The standard confirmation bapis allow posting of goods movements. I assumed you were doing goods movements to issue and consume material.

[Former Member]

Yes, as I wrote, I was consuming material, issueing material and confirming the order. Actualy, it is not so important what BAPIs are used. I described that situation only to get the meaning of the problem: lag between returning data from BAPI to MII and actual updating in ECC, so that sequences of BAPI calls are not working without predefined Pauses between them. There are plenty of such situation at my project not only with this BAPIs sequence.

And as Michael wrote my case is not unique.

Anyway, thanks for the answers!

[agentry_src]

Hi Petr,

There may be some settings on ECC which control the speed at which various processes are executed including confirmations. Since the BAPI is simply a wrapper around the ECC function module changing a setting to something like "immediate processing" or setting a priority level a bit higher may take care of your problems.

And I do not know the IMG files or other settings which would control it, but I think that is where the problem would be solved. I will check with a PP guy I know. Maybe he will know the answer right off the top of his head.

Regards,

Mike

[Former Member]

This has been a an issue for a long time. You can speed up r3 but it is still a race because sap will return without checking that all the locks are cleaned up. There are solutions when you are dealing with the issue in ABAP that basically amount to checking and waiting for any locks to clear. A popular solution is to put the call in a loop, check your return messages for the lock error and break the loop when you get a lock free call.