Set up of an ALE distribution model for customers master data - Part 2

IDocs generation

When your ALE distribution model is set up as presented in the part 1 of this article, you may start to generate IDocs to transfer data between your SAP systems. The first thing to do is to generate IDocs from your SAP data. For SAP standard objects such as customers master data, it is easy because SAP provides the necessary programs to store these objects into IDocs. To generate your DEBMAS IDocs that will contain your customers master data for example, you need to use transaction BD12. You only have to mention the customers numbers to send, the output type (which is the message type DEBMAS) and the logical system to which the generated IDocs will be sent. No other selection parameter is available because a more detailed restriction of the selection should occur based on the filters that have been set in the distribution model. So if you want to send only a specific company code view of your customers master data for example, you need to restrict the company code criterium in filters configuration.

This method of generating IDocs is handy when you need to mass transfer customers accounts from one system to another in a one shot operation. But it is not convenient if you need to synchronize several systems with the changes made to the master data in the source system. Indeed with such an interface you need to transfer regularly only the modified master data. ALE offers this possibility through the use of change pointers. These are indicators of data that has been modified and which can be converted to IDocs. They record changes that have occurred on specific data since the last time that data has been converted to IDocs through change pointers. Change pointers are normally not activated by default so you need to activate them generally and by message type in customizing. To convert the change pointers to IDocs, you need to run program RBDMIDOC in job preferably.

IDocs transfer

Depending on the settings you made in the partner profiles, the sending of generated IDocs and their treatment by the receiver(s) system(s) will require more or less external interventions.

The data sending and receiving methods you choose depend on the type of interface you are setting up which impacts directly the quantity and pace of the data transfer you foresee. Type of data processing chosen has a great impact on the resources used to generate and treat the IDocs and a badly configured interface could simply put your SAP system on its knees.

From my experience, the automatic sending of IDocs and their automatic treatment at receipt must be avoided. They put too much constraint on the servers as soon as the number of IDocs increases. To give you an idea of the workload generated in the receiving systems when processing is immediate at receipt, be aware that one dialog task of the server will be used per IDoc packet transferred (and a packet may contain only one IDoc!)... It is by far more secure to collect the IDocs in the sender system before sending them by packets and treat them in batch in the receiving systems. For a one shot interface (for data take on purposes for example), this is the only way to go and for permanent interfaces that transfer only changes this solution still presents a good balance between security, stability and synchronization time of the systems.

If you follow this recommendation and decide to go for an interface with data collection before treatment (this must be defined in the partner profiles), you will need to explicitely send your IDocs and treat them at receipt.

Sending IDocs

To send IDocs, you may either use a manual method or an automatic one (by running an ABAP program). To send Idocs manually, use transaction BD87 which is a central transaction to manage IDocs. You will find your IDocs in the sender system in the outbound IDocs under the message type DEBMAS.

You may opt for a more automated solution by scheduling the abap program RSEOUT00. Pay attention to choose the output mode 4 - collect and transfer - and to specify a high Maximum number of IDocs for good performance and low risk data transfer. This last number indicates the maximum number of IDocs that will make a packet. The default value of 5000 is acceptable in most situations.

Receiving IDocs

The receipt of IDocs in itself is automatic when transactional RFC communication method is used. But the treatment of the IDocs, understand their conversion and recording as SAP data, needs to be triggered if no automatic treatment at receipt has been chosen. To check the incoming (also called inbound) IDocs in your system, several transactions may be used. The most central one is BD87 as for outgoing IDocs which shows you your IDocs in the inbound section under the message type DEBMAS for customers master data. If everything is set up correctly, your IDocs should be present in that transaction with a status 64 indicating that they are ready to be passed to the application (in other words, ready to be treated). From transaction BD64, you may trigger the processing of the inbound IDocs you selected by selecting process command in the toolbar which starts the treatment of IDocs sequentially.

To automate the treatment of IDocs, you must run the ABAP program RBDAPP01 (transaction BD20) in job. This program has a very good option for parallel processing which can reduce a lot the time required for treatment. However use it carefully and make sure you set a packetsize high enough to avoid that your SAP system be overwhelm by demands for available dialog tasks (don't forget one dialog task is monopolized per IDocs packed to treat).

The program RBDAPP01 only treats IDocs with the specific status ready to be transferred to application. If your IDocs are in error for example, another program must be used. In fact there exists several programs to use depending on the status of the IDocs to treat. The general program RBDINPUT (to launch with SE38 or SA38) proposes a menu with the different statuses possible for inbound IDocs and launches automatically the right program according to the statuses you select.

Missing IDocs

If you cannot find your IDocs in the receiving system, you need to identify methodically the source of the problem. The following points should be checked:

• The status of IDocs in the sending system. They should be in status passed to port OK which indicates the IDocs were sent to the communication queue.
• The communication queue for transactional RFC to see if your IDocs are not stuck there. IDocs transit through that queue before being actually sent to the receiving systems thanks to the RFC connection. Any problem with the RFC connection will lead in the IDocs remaining in the queue. Check this queue using SM58.
• The status of IDocs in the receiving systems. The status might be different from what you expect if an error occurs while the IDocs are created in the receiving systems. Be sure not to restrict too much your IDocs selection and include all statuses, IDocs types, ... Usually a selection on the message type for a specific date is sufficient unless the system receives a lot of IDocs for the same message type on the same day.

Treatment of IDocs with errors

When treating IDocs in the receiving systems, you may encounter problems which are reflected by the IDocs statuses that indicate the type of error that happened during the treatment. Three main causes of errors exist:

• The control record of the IDoc does not match the settings of the partner profile of the sender system (example: message type missing in the partner profile).
• The data type of the data contained in the data record is not correct (syntax error).
• The data type of the data contained in the data record is not correct.
• An application error occurs while posting data. An error message provided by the application is stored in the IDoc in this case.

For the first two cases, a correction of the basis settings of ALE is needed before processing the IDocs again. A restart of processing or recreation of IDocs by the EDI administrator is necessary to post data. The third type of error (application error) is usually more functional and the intervention of a specific application consultant or business person is required. For this reason, these errors are usually solved through the use of a workflow procedure which requests the solution of the problem to the most appropriate person (or group of persons).

To understand the link between ALE and the SAP Business Workflow and how to customize this relation, it makes sense to try and better understand what's going on behind the scene.

To treat an inbound IDoc, SAP passes the IDocs data to a specific function module depending on type of the IDoc. This relation may be customized in transaction WE57 and the default function module for customers master data is IDOC_INPUT_DEBITOR which starts module ERP_IDOC_INPUT_DEBITOR which does all the job.

When this function module encounters an error during data conversion or data input, it returns the error to the calling ALE layer which triggers the corresponding object type event IDOC.inputErrorOccurred. For customers master data the object type is IDOCDEBMAS which you may inspect in the Business Object Builder (transaction SWO1).

This event is linked to the workflow task TS00008039 (use transaction PFTC to check it) and a workflow will start to correct the error if the event linkage is active.

The user(s) receiving the work item (= workflow step to execute) in his mailbox will execute it in order to input the IDoc data manually executing in fact the method InputForeground of the object type IDOCDEBMAS. When the input is successfully terminated, the work item disappears and the workflow terminates. If the error can not be solved, the work item may be marked for deletion so that it disappears from the inboxes.

As you may see, setting up the workflow to treat ALE errors is not a big work. You simply need to check that the event linkage of the task executing the method InputForeground of the object type associated with your message type is well active and then process the agent assignment of this task. You may need to create a specific HR organizational unit with transaction PPOME for this purpose. Of course, a preliminary step consists in checking that the general settings of Business Workflow are correctly set up but this applies to all workflows and goes behind the scope of this article.