Routine

[Former Member]

Hi,

What are processing routines?

what are function-pools.

[Former Member]

HI,

Sample Processing Routines

Creating and processing IDocs are a widely mechanical task, as it is true for all interface programming. We will show a short example that packs SAP R/3 SapScript standard text elements into IDocs and stores them back to texts in a second routine. The text elements can be edited with SO10.

Outbound function IDoc outbound functions are function modules with a standard interface which will read data from an application database and convert the data into IDoc format.

The interface parameters need to be compatible with a well defined standard, because the function module will be called from within another program.

Inbound function IDoc inbound functions are function modules with a standard interface, which will interpret the received IDoc data and prepare for processing by an application.

The received IDoc data is processed record by record and interpreted according the segment information provided with each record. The prepared data can then be processed by an application, a function module or a self-written program.

The example programs in the following chapters will show you how texts from the text pool can be converted into an IDoc and processed by an inbound routine to be stored into another system. The following will give you the basics to understand the example.

Text from READ_TEXT SAP R/3 allows the creation of text elements, e.g. with transaction SO10. Each standard text elements has a header record which is stored in table STXH. The text lines itself are stored in a special cluster table. To retrieve the text from the cluster, you will use the standard function module function READ_TEXT . We will read such a text and pack it into an IDoc. That is what the following simple function module does.

If there is no convenient routine to process data, the easiest way to hand over the data to an apllication is to record a transaction with transaction SHDB and create a simple processing function module from that recording.

Simple Example of processing routines.

Sample Inbound Routines

Inbound processing is widely the reverse process of an outbound.. The received IDoc has to be unpacked, interpreted and transferred to an application for further processing.

Inbound processing function module Below is the example of an inbound function module. This module expects an IDoc with rows of plain text and will save this text under a given name to SAP's text database. The procedure will extract the text name and the text line from the IDoc and hand over the text data to the function module READ_TEXT which will store the text in the text pool.

FUNCTION

*"----

-

---

""Lokale Schnittstelle:

*" IMPORTING

*" VALUE(INPUT_METHOD) LIKE BDWFAP_PAR-INPUTMETHD

*" VALUE(MASS_PROCESSING) LIKE BDWFAP_PAR-MASS_PROC

*" EXPORTING

*" VALUE(WORKFLOW_RESULT) LIKE BDWFAP_PAR-RESULT

*" VALUE(APPLICATION_VARIABLE) LIKE BDWFAP_PAR-APPL_VAR

*" VALUE(IN_UPDATE_TASK) LIKE BDWFAP_PAR-UPDATETASK

*" VALUE(CALL_TRANSACTION_DONE) LIKE BDWFAP_PAR-CALLTRANS

*" TABLES

*" IDOC_CONTRL STRUCTURE EDIDC

*" IDOC_DATA STRUCTURE EDIDD

*" IDOC_STATUS STRUCTURE BDIDOCSTAT

*" RETURN_VARIABLES STRUCTURE BDWFRETVAR

*" SERIALIZATION_INFO STRUCTURE BDI_SER

*"----

-

---

DATA: XTHEAD LIKE THEAD .

DATA: TLINES LIKE TLINE OCCURS 0 WITH HEADER LINE.

CLEAR XTHEAD.

REFRESH TLINES.

• *** --- Unpacking the IDoc --- ***

LOOP AT IDOC_DATA.

CASE IDOC_DATA-SEGNAM.

WHEN 'YAXX_THEAD'.

MOVE IDOC_DATA-SDATA TO XTHEAD.

WHEN 'YAXX_TLINE'.

MOVE IDOC_DATA-SDATA TO TLINES.

ENDCASE.

ENDLOOP.

• *** --- Calling the application to process the received data --- ***

CALL FUNCTION 'SAVE_TEXT'

EXPORTING

HEADER = XTHEAD

SAVEMODE_DIRECT = 'X'

TABLES

LINES = TLINES.

ADD SY-SUBRC TO OK.

• füllen IDOC_Status

• fill IDOC_Status

IDOC_STATUS-DOCNUM = IDOC_CONTRL-DOCNUM.

IDOC_STATUS-MSGV1 = IDOC_CONTRL-IDOCTP.

IDOC_STATUS-MSGV2 = XTHEAD.

IDOC_STATUS-MSGID = '38'.

IDOC_STATUS-MSGNO = '000'.

IF OK NE 0.

IDOC_STATUS-STATUS = '51'.

IDOC_STATUS-MSGTY = 'E'.

ELSE.

IDOC_STATUS-STATUS = '53'.

IDOC_STATUS-MSGTY = 'S'.

CALL_TRANSACTION_DONE = 'X'.

ENDIF.

APPEND IDOC_STATUS.

ENDFUNCTION.

Unpacking the IDoc data The received IDoc data is processed record by record and unpacking is a simple discrimination by case according the segment name provided with each record..

• *** --- Unpacking the IDoc --- ***

LOOP AT IDOC_DATA.bb

CASE IDOC_DATA-SEGNAM.

WHEN 'YAXX_THEAD'.

PERFORM UNPACK_IDOC TABLES IDOC_DATA USING XTHEAD.

WHEN 'YAXX_TLINE'.

PERFORM UNPACK_TAB TABLES IDOC_DATA TLINES.

ENDCASE.

ENDLOOP.

Application processing When the IDoc is unpacked it needs to be passed to the application. In our case this will be a simple call to a standard function which is going to store the data to the text database.

• *** --- Calling the application to process the received data --- ***

CALL FUNCTION 'SAVE_TEXT'

EXPORTING

HEADER = XTHEAD

SAVEMODE_DIRECT = 'X'

TABLES

LINES = TLINES.

Writing a status log Finally the processing routine needs to pass a status record to the IDoc processor. This status indicates successful or unsuccessful processing and will be added as a log entry to the table EDIDS.

• fill IDOC_Status

IF OK NE 0.

IDOC_STATUS-STATUS = '51'.

...

ELSE.

IDOC_STATUS-STATUS = '53'.

...

ENDIF.

APPEND IDOC_STATUS.

The status value '51' indicates a general error during application processing and the status '53' indicates everything is OK. There are numerous other status values, with distinct meanings, but '51' and '53' are the most common ones.

The REPORT and PROGRAM statements currently have the same function. They allow you to specify the message class of the program and the formatting options for its default list. Whether a program is executable or can only be started using a transaction code depends exclusively on the program type and not on the statement that introduces it. However, executable programs should always begin with a REPORT statement, and module pools always with a PROGRAM statement. Subroutine pools (type S programs) should also always begin with a PROGRAM statement.

FUNCTION-POOL

The introductory statement FUNCTION-POOL declares a program in which you can define function modules. At runtime, function pool programs are loaded in to a new program group with their own user dialogs and their own shared data areas in the internal session of the calling program. For this reason, function groups (type F programs) must always begin with a FUNCTION-POOL statement. This is usually generated by the Function Builder. Type 1, M, or S programs should not begin with a FUNCTION-POOL statement, since they would then not share common data areas with the caller. However, in exceptional cases, you can introduce a type 1 or type M program with FUNCTION-POOL to ensure that externally-called subroutines can process their own screens. As in the REPORT and PROGRAM statements, you can specify the message class and standard list formatting options of the program in the FUNCTION-POOL statement.

CLASS-POOL

The introductory statement CLASS-POOL can only be used for class or interface definitions (type K or J programs). A program introduced with the CLASS-POOL statement can only contain global type definitions and definitions of classes and interfaces. The CLASS-POOL statement is generated automatically where required by the Class Builder - you should not insert it into programs manually.

TYPE-POOL

The introductory statement TYPE-POOL can only be used for type groups (type T programs). A program introduced with the TYPE-POOL statement can only contain global type definitions and constants declarations. The CLASS-POOL statement is generated automatically where required by the ABAP Dictionary - you should not insert it into programs manually.

[Former Member]

Hi Keyur,

FUNCTION-POOL declares a program in which you can define function modules. At runtime, function pool programs are loaded in to a new program group with their own user dialogs and their own shared data areas in the internal session of the calling program. For this reason, function groups (type F programs) must always begin with a FUNCTION-POOL statement. This is usually generated by the Function Builder. Type 1, M, or S programs should not begin with a FUNCTION-POOL statement, since they would then not share common data areas with the caller. However, in exceptional cases, you can introduce a type 1 or type M program with FUNCTION-POOL to ensure that externally-called subroutines can process their own screens. As in the REPORT and PROGRAM statements, you can specify the message class and standard list formatting options of the program in the FUNCTION-POOL statement.

Regards,

Sunil.