Sending IDoc acknowledgement from SAP MII to SAP ECC

[Former Member]

Introduction:

In any SAP ECC and MII integration project one of the most common requirement is to send idoc from SAP ECC to MII. Different categories of data like production order, process order, material master or transfer order, can be sent to SAP MII system via an idoc.

Generally idoc received from SAP ECC system is admitted by sending an acknowledgement.

Using ALE audit, Idoc acknowledgement is sent to the sender system to monitor the status of an Idoc in the same system

           Fig:1

Middle systems like PI, has capability to send idoc in acknowledgement for idocs received from SAP ECC. For example, an ALEAUD01 idoc gets generated in PI system and is sent to ECC, whenever an idoc is received from SAP ECC. To achieve a better integrity, confirmations are dispatched periodically for a set of idoc, rather than for individual Idoc.

But MII as receiver of idoc has no capability to send idoc as acknowledgement. SAP MII receives Idoc through XMIIIdoc listeners and this process is asynchronous in nature. So for an asynchronous call an explicit response is required to confirm the message is successfully received by the receiver system. So as an alternative of sending acknowledgement through idoc, we can make use of an ECC function module and send the response.

As in MII we only can send data back to SAP ECC using RFC, to send the Idoc acknowledgement to SAP ECC from SAP MII we need one RFC.

Process Design:

In my current project, one of the primary requirements was to send idoc acknowledgement and set idoc status code (means application document created in target system) to 41 in SAP ECC.

We had mainly two options to implement this feature:

1. Using the standard RFC called IDOC_Asynchronous_Inbound which accepts multiple Idoc details but does not change the Idoc status.
2. Using standard ECC program RC1_Idoc_SET_STATUS which accepts multiple Idoc details and converts the Idoc status from one to another as well. But this program is not remote enabled and MII can’t use this program to do the needful.

As we were trying to achieve this functionality with least effort putting into it, we had to select the second option. In the second option RC1_Idoc_SET_STATUS program needs to be remote enabled with its input parameters and it should return message for each of the Idoc from the input list.

In our project we receive almost four types of idoc from ECC and each of them has different processing rules in MII. Irrespective of four different idoc types our primary goal was to develop a single set of program using which acknowledgements can be sent for all four Idoc types with different processing rules and also if required for additional MII idoc listeners for additional ECC clients.

Now let’s take a look into our proposed design for sending idoc acknowledgement to SAP ECC from SAP MII:    

       Fig:2 Process Flow

Solution Walk Through:

As mentioned above, we are receiving four different type of idoc from SAP ECC which includes LOIPRO, ZLOIPRO, MATMAS and CLFMAS through a single MII idoc listener called “XMIIIdoc01”. Among all these four idoc types two (MATMAS, CLFMAS) are processed by transactional processing rule and rest of them by categorized processing rule.

Also in future there is a possibility to receive more idoc types like WMTORD and WMCATO from single or multiple ECC systems.

For this development we used:

1. One MII scheduler
2. Four MII shared memory properties
3. One MII MDO persistent object
4. One MII MDO insert query
5. One MII BLS transaction to read categorized idoc data
6. One MII BLS transaction to call the RFC and send idoc acknowledgement to ECC
7. One MII MDO update query.
8. One MII MDO delete query.

1. MII Scheduler: We need one MII scheduler to trigger the MII transaction in the background when any Idoc comes to MII system. As per the requirement this scheduler is scheduled to run at every one minutes.

2. MII shared memory properties:  We have four shared memory properties to control the process of sending Idoc acknowledgement to ECC. They are as      follows:                                                         

• List of MII idoc listener (type - List): This is to maintain all configured MII idoc listeners and named as ConfiguredXMIIIdocListeners.
• List of idoc message types (type - List): This is to maintain the all the idoc types for which categorical processing rule has been defined. In our case these are like LOIPRO, ZLOIPRO and it’s named as IdocMessageType.
• Batch count (type - Integer): This batch count is to decide the number of idoc to be processed at a time. This may vary based on project scenario.
• Last Execution Time (type – TimeStamp): This is to capture the last successful execution time of the scheduler. So that in case of any error while executing the scheduler; no Idoc acknowledgement is missed from being sent to ECC.

3. MDO persistent object: To store each Idoc number with message type, timestamp (last modified time for each entry), old Idoc status (status from the Idoc itself), final   Idoc status (returned by ECC in the RFC response message) and a flag to indicate Idoc update status (N= Not updated, R= Running and Y= successfully updated).

4. MDO insert query: To insert the Idoc details in the MDO and this query is used inside logical transactions.

5. BLS to read categorized idoc data: This transaction first loops through all MII idoc listeners maintained in the ConfiguredXMIIIdocListeners shared memory property.      For each of the idoc listeners it loops through all message types found in IdocMessaeType shared memory property. Based on the Idoc listener and it’s message type it      queries all “categorized”,” received”,” running” and “failed” messages from the message service.

                                                                                                           Fig: 3

On receiving the Idoc details, inserts the details into the above mentioned MDO persistent object.

    

Fig 4: Idoc details in MDO

6. BLS to send idoc acknowledgement data to ECC: Inside this BLS we will make a call to the RFC to send the idoc acknowledgment data back to ECC. We are using here      the remote enabled SAP standard RFC called RC1_Idoc_SET_STATUS. This RFC has following parameters :

• P_Idoc = Idoc Number
• P_MESTYP = Message Type
• P_STANEU = New Status
• P_STATUS = Status

The RFC can handle multiple idoc data at a time. So from MII we will the sends a list of Idoc number, message type and new status in the RFC input. This program from ECC side provides the latest Idoc status and then the RFC gets executed to change the Idoc status to 41.

Fig: 5 RC1_Idoc_SET_STATUS in ECC

7. MDO update query: This MDO update query updates the status of the idoc in MDO and logs the response message from SAP ECC.

8. MDO delete query: We have different batch jobs to delete all transactional related data for production and transfer order. So when these batch jobs get executed , it will also call this delete query to delete the Idoc entry for which MII has successfully changed the Idoc status to 41 in ECC.

                                                                                                 Fig: 6

Error Handling:

            As sending acknowledgement to SAP ECC is a background process and there is no user interface to monitor the status of the Idoc, we had to define different ways to handle different type of error scenarios.

For network / connection issue and technical issues like “Netweaver database connection broken” , “Catalog service error” etc we have one persistent call or a mechanism to keep retrying the message sending process to the target system until MII finds the target system up and running or resolves the technical issue.

On the other hand, if there is any data issue, in that case RFC returns the error code and message for each of failed Idocs in each batch.

Based on the RFC response MII updates the “Idoc status update” flag to “N” (Not updated) in the MDO using the Idoc number and the message type.

So that next batch job can pick this failed one again to send the acknowledgment again to ECC.

  So far we have seen how we can send idoc acknowledgement from MII system. For additional message types, we can easily add in the shared memory list without any change in the code.