December 2007

IDOCS OUTBOUND TRIGGER PART TWO

The messages are typically processed byFORM ENTRY in PROGRAM RSNAST00.If we are dealing with printing or faxing andFORM EDI_PROCESSING in PROGRAM RSNASTED.If we are dealing with IDocsFORM ALE_PROCESSING in PROGRAM RSNASTED.

If we are dealing with ALE,The following piece of code does principally the same thing as RSNAST00 does and makes full use of all customizing settings for message handling.

TABLES: NAST.

SELECT * FROM NAST ...

PERFORM einzelnachricht IN PROGRAM RSNAST00

The processing routine for the respective media and message is customized in the table TNAPR. This table records the name of a FORM routine, which processes the message for the chosen media and the name of an ABAP where this FORM is found.The ABAP RSNAST00 is the standard ABAP, which is used to collect unprocessed NAST message and to execute the assigned action.

RSNAST00 can be executed as a collector batch run, that eventually looks for unprocessed IDocs. The usual way of doing that is to define a batch-run job with transaction SM37. This job has to be set for periodic processing and start a program that triggers the IDoc re-sending.

Cave! RSNAST00 will only look for IDocs which are set to NAST-VSZTP = '1' or '2' (Time of processing). VSZPT = '3' or '4' is ignored by RSNAST00.

Start RSNAST00 in the foreground first and find the parameters that match your required selection criteria. Save them as a VARIANT and then define the periodic batch job using the variant.If RSNAST00 does not meet 100% your needs you can create an own program similar to RSNAST00. The only requirement for this program are two steps:

* Read the NAST entry to process into structure NAST tables nast.

data: subrc like sy-subrc.....

select from NAST where .......

* then call FORM einzelnachricht(rsnast00) to process the record PERFORM einzelnachricht(rsnast00) USING subrc.

IDOC'S INBOUND PROCESS

IDOC'S BASIC TOOLS 2

IDOC'S BASIC TOOLS

ERP implementation process and advantages

ERP advantages and erp project launch

IDOC OUT BOUND TRIGGERS

IDocs should be sent out at certain events. Therefore you have to define a trigger. A lot of consideration is required to determine the correct moment when to send out the IDoc. The IDoc can be triggered at a certain time or when an event is raised. R/3 uses several completely different methods to determine the trigger point.

There are messages to tell the system that there is an IDoc waiting for dispatching, there are log files which may be evaluated to see if IDocs are due to send and there can be a workflow chain triggered, which includes the sending of the IDoc.

The simplest way to create IDocs, is to write an ABAP. The individual ABAP can either be a triggering ABAP which runs at certain events, e.g. every night, or it can be an ABAP which does the complete IDoc creation from scratch.A triggering ABAP would simply try to determine which IDocs need sending and call the appropriate IDoc creation routines.

You may also imagine the ABAP to do all the job. As this is mostly reinventing the wheel, it is not really recommended and should be reserved to situation, where the other solution do not provide an appropriate mean.You can use the R/3 message concept to trigger IDocs the same way as you trigger SAPscript printing.One of the key tables in R/3 is the table NAST. This table records reminders written by applications. Those reminders are called messages.

Every time when an applications sees the necessity to pass information to a third party. a message is written to NAST. A message handler will eventually check the entries in the table and cause an appropriate action.

The concept of NAST messages has originally been designed for triggering SAPscript printing. The very same mechanism is used for IDocs, where the IDoc processor replaces the print task, as an IDoc is only the paperless form of a printed document.The messages are usually be created using the condition technique, a mechanism available to all major R/3 applications.

The conditions are set up the same way for any output media. So you may define a condition for printing a document and then just change the output media from printer to IDoc/EDI or ALE.

Creating NAST messages is a standard functionality in most of the SAP core applications. Those applications - e.g. VA01, ME21 - perform calls to the central function module MESSAGING of group V61B. The function module uses customizing entries, mainly those of the tables T681* to T685*.

A NAST output message is stored as a single record in the table NAST. The record stores all information that is necessary to create an IDoc. This includes mainly an object key to identify the processed object and application to the message handler and the sender and receiver information.

IDOC'S INBOUND PROCESS

IDOC'S BASIC TOOLS 2

IDOC'S BASIC TOOLS

ERP implementation process and advantages

ERP advantages and erp project launch

ABAP IDOC'S INBOUND BASIC TOOLS 3

The declaration of valid combinations is done to allow validation, if the system can handle a certain combination.

The combination of message type and IDoc type determine the processing algorithm. This is usually a function module with a well defined interface or a SAP business object and is set up in table EDIFCT.The entry made here points to a function module which will be called when the IDoc is to be processed.

The entries for message code and message function are usually left blank. They can be used to derive sub types of messages together with the partner profile used. Figure Assign a handler function to a message/message type The definition for inbound and outbound IDocs is analogous. Of course, the function module will be different.

uses the method of logical process codes to detach the IDoc processing and the processing function module. They assign a logical name to the function instead of specifying the physical function name.

The IDoc functions are often used for a series of message type/IDoc type combination. It is necessary to replace the processing function by a different one. E.g. when you make a copy of a standard function to avoid modifying the standard. The combination message type/IDoc will determine the logical processing code, which itself points to a function. If the function changes, only the definition of the processing codes will be changed and the new function will be immediately effective for all IDocs associated with the process code.

For inbound processing codes you have to specify the method to use for the determination of the inbound function.

This is the option you would usually choose. It allows processing via the ALE scenarios.

After defining the processing code you have to assign it to one or several logical message types. This declaration is used to validate, if a message can be handled by the receiving system.The inbound processing code is assigned analogously. The processing code is a pointer to a function module which can handle the inbound request for the specified IDoc and message type.

The definition of the processing code is identifying the handler routine and assigning a serious of processing options.You need to click "Processing with ALE", if your function can be used via the ALE engine. This is the option you would usually choose. It allows processing via the ALE scenarios.

Associate a function module with a process code For inbound processing you need to indicate whether the function will be capable of dialog processing. This is meant for those functions which process the inbound data via call transaction. Those functions can be replayed in visible batch input mode to check why the processing might have failed.