Interface programming in ABAP COMMUNICATION INTERFACE lesson 6

ASYNCHRONOUS DATA TRANSFER:

One of the prerequisites of CPI-C communication is that the recipient system is available.
Asynchronous data transmission (or buffered data transmission) is useful for cases where the recipient system is unavailable or overloaded (and so unable to receive and process data).

The data that is to be sent is first placed in a queue. Then a job is automatically scheduled that starts an active CPI-C send program (driver program) at the set time to read and send the queue data.
You specify the recipient passive program in the queue attributes, which is then called at the appropriate time to receive and process the data.


The system only schedules the transmission job for queues with the value 'A' (automatic transmission) in the 'Start mode' attribute.

The job has the same name as the queue, and is scheduled for the time and date specified in the 'Transmission date/time' attribute. The only step in the job is to call the active CPI-C program specified in the 'Driver program' attribute of the queue.


The specified driver program is started automatically at the chosen start time. This active CPI-C program calls the relevant recipient program and sends the queue to it. The driver program reads the relevant parameters for the CPI-C communication from the corresponding queue attributes.

The SAP standard driver program, RSQAPI20, has the following properties:
- If the connection to the remote system cannot be established, the driver program schedules itself again (-> new job). You can set the interval between attempts using the constant DELAYTIME in the driver program. (300 sec.) .

- If the 'CLIENT' attribute (client in remote SAP system) is set; the corresponding CPI-C connect string is constructed and sent automatically after establishing the connection with the remote system.

The queue records are then read and sent in ping pong mode.
LUWs that have been sent successfully are deleted from the queue (an LUW is a set of records that belong together). (LUW = records that belong together)

- If the connection is terminated when the data is transmitted, the current LUW in the queue is rolled back, the queue status is set to 'E' and an express mail is sent to the queue creator.

(In this error case the recipient program must roll back the current LUW in the remote system itself.). If required, you can adapt the driver program to your own needs, or write your own driver program for use in queue transmission.

You must create a passive recipient program in the remote system that can receive and process the queue data.

CREATE A QUEUE.

OPENING QUEUE:

When you open a queue using the function module QUEUE_OPEN, you must supply the following parameters:

NAME Name of queue to be opened

This parameter is not specified when opening a new queue.The queue therefore the queue receives the current time stamp as its name, which you receive from the
export parameter NAME of the function module.)

OPENMODE 'W' Write ; ' R ' : Read

ERASE ' X ' : Deletes the queue shell when the queue is empty


TYPE ' U ' : Unique (Queue can only be filled with data once,

cannot subsequently be extended) Appendable (Queue may be extended, even during transmission)

START ' A ' : Automatic (queue data is automatically sent via an internally scheduled job at the specified send time (DATE / TIME).

' M ' : Manual (queue must be sent manually using Transaction SM38) -> internal scheduling of an immediate job)


'E' : Event controlled (Used to start transmission immediately once the queue has been created.) To do this, you must manually create an appendable queue from the start mode 'E' first using Transaction SM38. When the queue is activated, a job is created internally that is executed at the event SAP-QEVENT / parameter . If you place data from this program in this queue, the accompanying event is triggered automatically at QUEUE_CLOSE. The scheduled job for sending data begins running.

DATE/TIME Transmission start time and date (only applies to start type 'A').



The function module QUEUE_PUT requires the following input parameters:
NAME Name of the queue into which you want to place the record.
SATE Position of the current record within its LUW:
' S ' : Current record is the only record in the LUW
'F': Current record is the first (but not only) record in the LUW
SAPCE: Current record is neither the first nor the last record in the LUW
'L': Current record is the last of several records in the LUW
BUFFER Current record
LENGTH Length of current record



The function module QUEUE_CLOSE requires the following input parameters:
NAME Name queue to be closed

OPENMODE Open mode used when queue was opened

If you created the queue with start mode 'A' (automatic transmission), the corresponding job is scheduled automatically when you call QUEUE_CLOSE. The job name is the same as the queue name.



If you modify driver program RSQAPI20 or write your own driver program, you can use the above function modules to read or delete queues. For further information about their use, refer to their documentation in the Function Builder.



You can administrate queues in the queue pool using Transaction SM38.

The standard R/3 System contains the following demonstration programs, which show how to create a queue and send and receive data:
Creating a queue: SAPBC415D_CREATE_QUEUE or RSQAPI10
Sending data: RSQAPI20 (Standard driver program)
Receiving data: RCVQDATP (Passive recipient program in the remote system)

Interface programming in ABAP COMMUNICATION INTERFACE lesson 5

CALLING AN ABAP PROGRAM REMOTELY :

You can call ABAP programs (or more precisely, ABAP form routines) in an R/2 or an R/3 System remotely using CPI-C. However, you cannot communicate with them
directly.

Instead, the connection must be made via the SAP Basis System of the passive program.


In the R/2 System, the SAP Basis System is the task handler, called using X1SA. In the R/3 System, it is the dispatcher which you address using sapdpxx.







The above procedure for calling a remote ABAP routine is the same, regardless of whether the active program is an ABAP program in an R/2 or an R/3 System, or a C program in an external system.



The valid format for a connect string is contained in the ABAP Dictionary structure CPICCONN. Defining a structure with reference to it is the easiest way to create your own connect string.

If you are programming in C, use the call SAP_CMLOGON to create a connect string in EBCDIC.


All of the values in a connect string must be entered in uppercase.

In the NAME field, enter a user with type CPI-C that is already defined in the relevant client of the remote system.

The one-character language key is converted into the corresponding two-character key by the remote Basis system. This must be made known to the remote system.


In the PROG field, enter the main program of the remote routine. The syntax must be correct. The name of this main program may have a maximum of 8 characters.

The form routine that you enter in the MODN field must exist within the specified main program.


If the remote Basis system's check on the connect string is positive (valid logon data, main program and form routine syntactically correct, and both exist in the target system), the active program receives the 12 byte EBCDIC string 'APPCCPIC1' with the return code 0 and send permission. As of this point, the system can communicate directly with the called ABAP routine. The data format is completely open.


If the checks fail, the remote Basis system sends a corresponding error message with the 12 byte header 'FREECPIC1' in EBCDIC and terminates the connection.


DEVELOPMENT AND TEST ENVIRONMENT :




In R/3, the CPI-C calls are contained in the language scope of ABAP.

However, on external platforms you must install the CPI-C library (CPI-C-SDK). How to use the CPI-C calls is described in the text files and sample programs delivered with the SDK.




The standard system contains the CPI-C test programs ACPICT1 and ACPICT2 (in R/2 from Release 5.0G). ACPICT1 is an active CPI-C program, ACPICT2 is a passive CPI-C program. You can use them to test R/3 - R/3 and R/3 - R/2 CPI-C connections.

SAP also supplies the SAP CPI-C SDK (Software Development Kit) with every SAP R/3 System. This helps you to develop CPI-C programs in C. The SDK contains the C programs ccpict1t (active) and ccpict2t (passive).

You can use these to test connections between two external systems, but, above all, to test connections between external systems and an R/3 System. ccpict1 can call not only ccpict2t remotely, but also the passive ABAP program ACPICT2. Likewise, the active ABAP program ACPICT1 can call the passive C program ccpict2t.

When you run ACPICT1, you must specify:
- If ACPICT2 or ccpict2t should be called remotely (parameter 'ABAP') ,
- If test data should be converted from ASCII to EBCDIC (parameter 'CONVERT').

If you choose to call ACPICT2, you must also enter the logon data for the connect string on the selection screen of ACPICT1.




You can use the Debugger to analyze an active ABAP CPIC-C program in R/3. This does not apply in R/2, since screen changes are not allowed in R/2 during a CPI-C connection (Debugging involves screen changes). You cannot analyze passive programs in the Debugger.


you can use the Gateway monitor (Transaction SMGW) to monitor SAP Gateway activity (existing CPI-C connections) and generate and display gateway traces.

One of the tasks of the system log is to record failed CPI-C logons that have been sent from remote systems to the current system. You can display the system log using Transaction SM21.

Interface programming in ABAP COMMUNICATION INTERFACE lesson 4

The COMMUNICATION RECEIVE statement causes the transmission of the send buffer along with the send permission, and waits for data.
Parameters:


ID Conversation ID

Length Use this parameter to specify which part of the specified receive buffer should be used. Optional; if you do not specify a length, the system uses the whole receive buffer. The field must have type P.

HOLD This addition (without a field) causes the work process to be stopped (no roll- out/roll-in) while it waits from the RECEIVE.
You would use this, for example, when using RECEIVE within a SELECT loop.

Output:

BUFFER Receiving buffer (contains data received)

RECEIVED Number of character received This field must have the type X4.

DATAINFO Information on whether the receive buffer was large enough for the

incoming SEND packet. This field must have the type X4.

STATUSINFO Information on the sender authorization. This field must have the type X4.

RETURNCODE



The return parameter DATAINFO specifies whether data has been received and whether the receive buffer (or section of the buffer) was large enough to receive the entire SEND packet.

DATAINFO can have the following values:

CM_NO_DATA_RECEIVED --> No data received
CM_COMPLETE_DATA_RECEIVED --> Data received and RECEIVE buffer is large enough
CM_INCOMPLETE_DATA_RECEIVED --> Data received but RECEIVE buffer to small to receive entire SEND packet. (In this case, the remaining segments must be transmitted as long as there are other RECEIVEs to be received, until DATAINFO has the value CM_COMPLETE_DATA_RECEIVED.)


The return parameter STATUSINFO indicates whether send permission has also been received. STATUSINFO may take the following values:
CM_NO_STATUS_RECEIVED --> No send permission received
CM_SEND_RECEIVED --> send permission received



You use this call to close the CPI-C connection. Any data in the local buffer that has not yet been sent is transmitted first.

The connection should always be closed by the program with send permission, otherwise, any data that has not yet been received is lost.


Data conversion is necessary when two systems that use different character sets communicate with each other.

To convert the character sets, you use the ABAP command
TRANSLATE FROM CODE PAGE '. . .' TO CODE PAGE '. . .'
This lets you convert between of different code pages. The contents of the field you specify is converted from the source code page representation to the target code representation.

Interface programming in ABAP COMMUNICATION INTERFACE lesson 3

The COMMUNICATION RECEIVE statement causes the transmission of the send buffer along with the send permission, and waits for data.

Parameters:

ID Conversation ID
Length Use this parameter to specify which part of the specified receive buffer should be used. Optional; if you do not specify a length, the system uses the whole receive buffer. The field must have type P.

HOLD This addition (without a field) causes the work process to be stopped (no roll- out/roll-in) while it waits from the RECEIVE.
You would use this, for example, when using RECEIVE within a SELECT loop.

Output:

BUFFER Receiving buffer (contains data received)
RECEIVED Number of character received This field must have the type X4.
DATAINFO Information on whether the receive buffer was large enough for the incoming SEND packet. This field must have the type X4.
STATUSINFO Information on the sender authorization. This field must have the type X4.
RETURNCODE


buffer (or section of the buffer) was large enough to receive the entire SEND packet.


DATAINFO can have the following values:


CM_NO_DATA_RECEIVED --> No data received
CM_COMPLETE_DATA_RECEIVED --> Data received and RECEIVE buffer is large enough
CM_INCOMPLETE_DATA_RECEIVED --> Data received but RECEIVE buffer to small to receive entire SEND packet. (In this case, the remaining segments must be transmitted as long as there are other RECEIVEs to be received, until DATAINFO has the value CM_COMPLETE_DATA_RECEIVED.)


The return parameter DATAINFO specifies whether data has been received and whether the receive The return parameter STATUSINFO indicates whether send permission has also been received. STATUSINFO may take the following values:

CM_NO_STATUS_RECEIVED --> No send permission received
CM_SEND_RECEIVED --> send permission received


You use this call to close the CPI-C connection. Any data in the local buffer that has not yet been sent is transmitted first.

The connection should always be closed by the program with send permission, otherwise, any data that has not yet been received is lost.




Data conversion is necessary when two systems that use different character sets communicate with each other.

To convert the character sets, you use the ABAP command
TRANSLATE FROM CODE PAGE '. . .' TO CODE PAGE '. . .'
This lets you convert between of different code pages. The contents of the field you specify is converted from the source code page representation to the target code representation.

Interface programming in ABAP COMMUNICATION INTERFACE lesson 2

THE CPI-C COMMUNICATION INTERFACE :

The SAP CPI-C interface allows ABAP programs in an R/3 or an R/2 System and external C programs to communicate with each other and exchange data.

Communication via CPI-C is necessary if RFC is not available.



CPI-C (Common Programming Interface for Communications) is a standardized program-to-program communication interface that originated at IBM. It consists of a set of calls with which two programs can communicate with each other.

SAP supports the CPI-C interface for ABAP and C programs.


REMOTE DESTINATIONS:


To start communication with a partner using CPI-C, the active program has to have an entry in the side information table (sideinfo entry). This entry contains all of the necessary communication parameters.

For each remote partner you want to call you must have a corresponding sideinfo entry. These sideinfo entries are also known as 'symbolic destinations'.

The sideinfo table in the SAP R/3 System is called TXCOM. You maintain it using Transaction SM54.


To start a communication between two R/3 Systems, you need an entry in the side info table TXCOM in the active (source) system.

Contents:

Dest : Any logical name (name of the sideinfo entry)

Prot: ' I ' (protocol type for R/3-R/3 connection)

GW host: Host on which the requisite gateway is running

GW Service : TCP/IP service for gateway to be used

(If the two fields GW host and GW service are not set with values, the default gateway of the current application server is used when making the connection.)

LU : Application server of the passive R/3 System (target system)

TP: TCP/IP service of the dispatcher of the passive R/3 System (target system)



To communicate between an R/3 System and an IBM R/2 System, you need an SNA gateway (SAP Gateway with SNA functions), on which an LU6.2 product is running as well as TCP/IP. We recommend installing the SNA gateway as a dedicated standalone gateway that can be used by various R/3 application servers to communicate with SNA LU6.2 systems.

To connect to an IBM R/2 System from an R/3 System, you need an entry in the sideinfo table TXCOM in the R/3 System, and an entry in the sideinfo table of the SNA Gateway.
TXCOM entry:
Dest : Name of sideinfo entry (must match with name of corresponding gateway sideinfo
entry)
Prot : ' C ' (Protocol type for R/3-R/2 connection)
GW host / GW service : Host and TCP/IP service of the SNA gateway
LU / TP: No meaning

Sideinfo entry on the gateway (see diagram): Contains the entry name (must match the corresponding TXCOM entry), and SNA entries about Logical Unit (LU) for the R/2 host (remotely called), and the R/2 task handler (TP = X1SA) (For information on maintaining the gateway sideinfo table, see the online documentation)

You can also install the SNA gateway on the host side. The advantage of running the SNA gateway on the IBM host is that you can use existing TCP/IP and LU6.2 software for the gateway on the host side.



To communicate between an R/3 System and a Siemens R/2 System, you need an SAP gateway running on the Siemens host that can be addressed using TCP/IP.
(TCP/IP functions on the host side are available from BS2000 version 10, DCAM version 11.)

You can operate the host gateway with or without sideinfo.
(Setting in host file SAPGW.RSPARAM , parameter bs2/use_sideinfo [0,1] )
You may have to maintain a corresponding sideinfo entry for the host gateway.
Refer to the documentation for maintaining the gateway sideinfo table.

To connection an R/3 System to a Siemens R/2 System, you need an entry in the sideinfo table TXCOM in the R/3 System.

TXCOM entry:

Dest : Name of the DCAM or UTM application (SAP System) to be called by the gateway or name of the gateway side info entry.
Prot: ' C ' (Protocol type for R/3-R/2 connection)
GW host / GW service : Host name / TCP/IP service of the host gateway

LU / TP : No meaning


UNIX: Calling an external program over the SAP gateway occurs with the user that started the gateway (for example, t79adm). This user must have the correct start authorization.

If the SAP gateway does not run on the same host as the external program, it is started by remote shell from the gateway. The user who started the SAP gateway must also exist on the host of the external program. (The program is called in its name). The .rhost (remote shell authorization) on the remote machine must also have a corresponding entry.

OS/2 : As with UNIX, but without user ID.

NT : Like OS/2, the SAP gateway must run on the same host as the external program because the remote shell function with Windows NT.

LU6.2 systems:
You can also reach external LU6.2 systems using the SAP SNA gateway. For example, you can call a Cobol program running in CICS using CPI-C from an R/3 System. The sideinfo table is maintained in the same way as the R/3 -->R/2 (IBM) communication scenario which you see in the online documentation.

Windows 3.1 , WfW :
- No CPI-C
- RFC only for the current front end


USING CPI-C IN COMMUNIATIONS :

The program that initiates the connection is called the active program, or client.

The program that is called is known as the passive program, or server.

To start a CPI-C connection, the active program must initialize it, that is, use a CPI-C call to read the necessary communication parameters from the corresponding sideinfo entry.

These parameters are then stored under a conversation ID (output of the CPI-C call) and are used when the connection is made. After being accepted by the target program the connection is available for data exchange.

CPI-C is a half-duplex communication method, that is, only one side may send data at a time.

Once the passive program has accepted the communication, the active program may send data first, while the passive program has to wait for data using a receive call.

CPI-C transmission is asynchronous. The send buffer is transmitted, along with permission to send, when the sending side submits its next receive command.

The connection may only be closed by the program that is currently permitted to send data (otherwise data may be lost). The partner program waiting with the receive command then receives the corresponding return code (18).


The term 'ping pong' describes the communication method described above, in which an acknowledgement is sent after each data record.


In contrast to the 'ping pong' method, 'multisend' sends a series of data records before receiving a single acknowledgement at the end.

Comparison of the two communication methods:

The ping pong method involves more work because you are dealing with single records and individual acknowledgements, whereas multisend uses a single asynchronous send, and only has to wait for one overall acknowledgement.

However, ping pong provides you with better control of your data. If the communication is broken (communication error, or the receiving program crashes - return code 17), you always know, if you are using ping pong, which records have arrived in the target system, which have been processed, and where you need to resume processing.

The multisend method, on the other hand, also returns the code 17, but does not know which records have been received, and if they have been fully or partially processed, or not processed at all.


Therefore use the ping pong method where each data record contains, for example, the data for one transaction.


You use the following ABAP statements to run a CPI-C (ABAP) connection:


COMMUNICATION INIT Initialize connection
COMMUNICATION ALLOCATE Make (allocate) connection
COMMUNICATION ACCEPT Accept connection
COMMUNICATION SEND Send data
COMMUNICATION RECEIVE Receive data
COMMUNICATION DEALLOCATE Close connection


External C programs use the same calls to communicate with ABAP programs using CPI-C.

Although the syntax of the calls is different in C (CMINIT, CMALLC, CMACCP, CMSEND, CMRCV, CMDEAL), their functions are the same as the corresponding ABAP calls.


The return code of a CPI-C call in ABAP is always placed in the field SY-SUBRC. However, it can also be placed in the RETURNCODE parameter of the CPI-C call itself.

As well as the return code, some CPI-C calls also return special parameters containing extra information about, for example, data transfer and which side is entitled to send data.

The return codes and return parameters of CPI-C calls are stored as hexadecimal codes. When you query the codes, you should use meaningful constants instead of the hex codes.

Use IF RC = CM_DEALLOCATED_NORMAL instead of if RC = 18 to close the connection from the partner side.
The CPI-C constants are contained in the standard ABAP include RSCPICDF.

The most important return codes are:

'0000'( CM_OK ) :Connection OK
'0011'( CM_DEALLOCATED_ABEND ) :Connection terminated
'0012'( CM_DEALLOCATED_NORMAL ) :Connection from partner terminated normally
'0013'( CM_PARAMETER_ERROR ) :Invalid conversation ID in CPI-C call
'0014'( CM_PRODUCT_SPECIFIC_ERROR ) :Invalid sideinfo entry in CMINIT call
'0019'( CM_PROGRAM_STATE_CHECK ) :Send command rejected due to missing send authorization


COMMUNICATION INIT This is used to initialize the CPI-C connection.
(Preparing the connection)

Entry:

DESTINATION Name of sideinfo entry

Output:

ID Conversation ID This indicates the communication partners for the specified sideinfo entry.
It is used until the next connection is made and is at the same time the name of the connection.

RETURNCODE Return code of the call is always stored in SY-SUBRC; can be used in additional fields.
This parameter is optional.

The fields listed in the INIT call must have the following types:
dest C8
convid C8
rc X2

Legend: lowercase + cursive --> ABAP field
underlined --> Entry variable
[ ... --> optional entry


COMMUNICATION ALLOCATE builds the CPI-C connection and the corresponding partner program is started. You must specify the conversation ID returned by the INIT call.


For a valid connection to be established, the called program must accept the connection using the COMMUNICATION ACCEPT statement. The ACCEPT call returns the conversation ID of the connection and a return code. This must be the first statement in the passive program.

After the ACCEPT call from the side that was called, the active program has the send permission. The passive program must first receive.


In the send command, you can send a data packet of up to 30000 bytes.
Parameters:

ID Conversation ID

BUFFER Send buffer (max 30000 bytes)

LENGTH Length of the packet you want to send (optional; if entries are missing, the entire send buffer is sent) The field must have type P.

Output:
RETURNCODE
If a program sends without having permission, the return code is 25 (Hex 19)

Interface programming in ABAP COMMUNICATION INTERFACE

The SAP R/3 System has a modular software architecture that follows the software-oriented client/server principle.

The system distributes presentation, application logic, and data storage across hosts at different levels. This forms the basis of its scalability.

The lowest level is the database level. The data is administrated on this level using a relational database management system (RDBMS). As well as master and transaction data, it also stores programs and the metadata that describes the R/3 System and the structure of its data.

The second level is the application layer. This consists of ABAP programs. You can complement the existing SAP functions by writing your own programs using the ABAP Workbench.

The third level is the presentation layer (SAPgui). It contains the user interface with which end users enter and display data. You can also use alternative front ends (AFEs) at this level.

Communication interfaces and data interfaces are different. In addition to the file I/O, the communication interfaces are the gate to external communication, while the data interfaces are used for read and write accesses to the R/3 database.

The following data interfaces are available:
Batch Input, Direct Input, CALL TRANSACTION USING, SAP-SQL (OpenSQL), Native SQL.


An instance is an administrative unit in an R/3 System. It describes which services (dialog, update, enqueue, background, spool gateway) are available . .) on the corresponding application server.

The dispatcher process on an application server coordinates tasks within an instance. It communicates with other instances in the same R/3 System via the message server, and with external systems via the gateway. As of Release 3.0, a gateway service (work process) belongs to each instance (application server). You can also install a gateway service on a non-R/3 host.

When an application server communicates (dispatcher) with external systems, it usually uses its own gateway work process. However, it may be more useful to use a gateway that runs on a dedicated host, for example, for communication with SNA, where a gateway with an add-on is required.

This is done to minimize the effort needed for configuration and maintenance (the gateway add-on is only on one host instead of each application server). You may have to use a remote gateway, for example, with remote Windows NT applications, because the remote program can only be started via this gateway.


R/3 communication always runs through the SAP gateway and is based on TCP/IP.

For R/3 communication with an IBM-R/2 System or other LU6.2 systems, where the LU6.2 transport protocol is used, you need an SAP gateway with additional SNA functions.


RFC is based on CPI-C, which means an RFC call is always transmitted in CPI-C calls.
CPI-C can be based on TCP/IP or LU6.2, depending on the platform.

SUBMIT a Program using ABAP function module

If you wish to SUBMIT a program you can do so by using the SUBMIT statement or you can use the following function module. Once the called program executes the control is returned to the calling program.

RZL_SUBMIT

Please find the code below.

REPORT ZEX_FUNCCALLPROG .


Parameters: p_prog like sy-repid.


CALL FUNCTION 'RZL_SUBMIT'
  EXPORTING
    REPID         = p_prog
          .


Write:/ 'Control Returned'.

SAP ABAP Keywords for program practise.

The following list displays some of the important Keywords in ABAP

No	Keyword	Description
1	AT END OF … ENDAT	Control group end in LOOP
2	AT Fg … ENDAT	Processing specific to record type in LOOP
3	AT FIRST … ENDAT	Execute processing block within a LOOP before processing single lines
4	AT LAST … ENDAT	Execute processing block within a Loop after processing single lines
5	AT NEW … ENDAT	Control group end during LOOP
6	CALL	Call processing (Program, function module, screen)
7	CHECK	Selection condition, leave loops and subroutines
8	CONTINUE	Exit current loop pass within a DO, WHILE, LOOP or SELECT loop
9	DO … ENDDO	Loop processing
10	EXEC SQL … ENDEXEC	Execute a Native SQL Statement
11	EXIT	Leave loops or subroutines
12	FORM … ENDFORM	Definition of a subroutine
13	IF … ELSE … ENDIF	Conditional processing
14	LEAVE	Leave program processing, go to a transaction, list (or) menu
15	LOOP … ENDLOOP	Loop on a table (or) extract dataset
16	MODULE … ENDMODULE	Definition of a dialog module
17	ON CHANGE OF … ENDON	Processing on field change
18	PERFORM … USING	Call a subroutine
19	SELECT … ENDSELECT	Read database tables
20	STOP	End selection
21	WHILE … ENDWHILE	Loop processing

Workflow Data for MASS approval leave - PT_ARQ_REQUEST_EXECUTE

When there is a requirement for approving the mass approvals for the leave request workflow , then use the below function module PT_ARQ_REQUEST_EXECUTE to approve it.

Before running the functional module check the record status in the table PTREQ_HEADER with field status. It has the status 'SENT' .

data : EX_MESSAGES TYPE PTARQ_UIA_MESSAGES_TAB,
EX_COMMANDS TYPE PTARQ_UIA_COMMAND_TAB.

CALL FUNCTION 'PT_ARQ_REQUEST_EXECUTE'
EXPORTING
im_request_id = 'E079F211C65FEFF188150050569A609B' "PTREQ_HEADER-REQUEST_ID
IM_COMMAND = 'EXECUTE_APPROVE'
im_pernr = '00000001'
im_modus = 'R'
* IM_DEBUG =
* IMPORTING
* EX_REQUEST =
* EX_HAS_ERRORS =
* EX_SHOW_CHANGE =
tables
ex_messages = EX_MESSAGES
ex_commands = EX_COMMANDS
.

After running this function module the status become 'APPROVED' in the table PTREQ_HEADER , and if u check in the workflow the workflow would be completed. for detailed data run the report RPTARQDBVIEW.