aRs's question regarding shared memory objects created in ECC APO CIF exits

[Former Member]

In a thread below, aRs asked a very interesting question:

We invoke the CIF for an integration model by kicking off the batch program RIMODACT on an ECC server (note that this program is not defined on the APO server.)

Then, during the RIMODACT execution of the CIF, we call our implementation of the BAdI SMOD_APOCF005 that's defined on the APO server (you can't see this BAdI in SE18 on the ECC server.)

And in our implementation of the BAdI, we want to builda shared memory object.

So where shoudl the root and area class be defined:

a) on the ECC server (where RIMODACT is running)?

b) on the APO server, where the BAdI lives?

Part of the answer may be that RIMODACT on the ECC server simply calls a remote-enabled FM on the APO server, and the BAdI executes out of that FM.

In that case - the answer is obvious - the shared memory object must be defined on the ECC server ...

I'm going to check out RIMODACT now ... maybe I can answer this one myself.

Edited by: David Halitsky on Feb 20, 2008 6:47 PM

[former_member181923]

This note in RIMODACT seems to indicate that the actual CIF "work" actually happens on the APO server:

• BEGIN NOTE 641858*

• Order changes must be adopted by APO in exactly the same order*

• they happened in R/3. That's why CIF uses a queued RFC and puts the*

• order number in the queue name to transfer an order.*

• The CIF default issues one qRFC per queuename, resulting in as*

• many qRFCs as there are distinct order numbers. However, APO could*

• process these orders faster if they came in a single call. So for*

• transactions which touch a lot of orders in the same LUW (and pass*

• all the orders to CIF as a whole) we can get better performance if*

• we bundle these orders in a single qRFC to APO instead of splitting*

• them up into different calls. Since we still have to follow the*

• serialization rules, this one call must be registered to all queue-*

• names resulting from the order numbers.*

• However, most transactions will pass single data records to CIF*

• anyway so there's nothing really to bundle. An exception for which*

• it makes sense is the MRP run.*

• To turn this 'bundling' on, you must create an entry in table TVARV*

• indicating for which object types this bundling should happen. Use*

• the name as given in the constant below and enter a selection range*

• for the object type as they appear in constant GC_IMTYP above.*

• NOTE! Bundling is currently supported only for object types*

• T_PO - purchase orders & requisitions*

• T_ORD - production orders*

• T_PLO - planned orders*

• T_STK - stock / goods movements*

• T_MARD - all(!) stock / goods movements*

• T_SLS - sales data (sales order, delivery)*

If that's the case, then the job which executes RIMODACT on the ECC server must be followed by a jov which executes the program that calls the BAPI's on the APO server.

The BAPIs will still be able to access the shared memory object, because it was built during exection of the CIF BAdI on the APO server.

Agreed ??