Integrating Scheduler Software with SAP PI

[deepak_shah]

                         This blog describes a solution to integrate file scheduler with SAP PI. Large enterprises mostly use scheduling software (For e.g. Control-M) for scheduling their file interfaces (both Inbound & Outbound File interfaces). Job of the file scheduler in case of outbound file interface is to fetch the file from legacy systems and place it onto PI application server from where PI file channel will pick up the file to trigger message processing. In case of inbound interface, once the file has been created on target folder, scheduler will move the file from PI application server to legacy system. The solution is based on the idea of generating status files on PI Application server with appropriate names at several stages of message life cycle. These status files will in turn notify the file scheduler about the status of the interface at appropriate stage. We can have a designated monitoring folder on PI application server wherein these status files are created. File scheduler will in turn monitor this folder for the status files and update the jobs accordingly.

Requirement:  File scheduler software is used for controlling (start/stop of channels) the file interfaces. So the scheduler wanted to know the status of the message in PI and ECC system so that it can update its Batch jobs accordingly.So we had to generate these status files (with fixed file name format) so as to let the scheduler know the status of messages in each system.

Approach for INBOUND & OUTBOUND file based interfaces:

A.  Outbound File Interfaces:

1. For Outbound cases, File scheduler will move the file from any legacy system to PI application server designated folder. PI will do subsequent processing to put the data in ECC system (via proxy).
2. Once the file is available in application folder scheduler will start the PI channel and when file disappears, stop PI channel when file disappears to confirm PI channel picked up the file.
3. Once the file disappears, schedule the 2nd file watcher to poll for the status files. Statuses can be defined based on file names.
4. If processing fails in PI then PIFAIL file will be created on PI application server and the Jobs will end at this point.
5. If Data is passed from PI to ECC system successfully, however fails in Back-end system then ECCFAIL file will be created on PI application server.
6. If message is processed successfully in backend system then ECCOK file will be created.

B.  Inbound File Interfaces:

1. For Inbound cases, Schedule the back end job that will send data to SAP PI.
2. On receiving completion confirmation of batch job in ECC system, schedule a file watcher for the designated file in designated folder.
3. If the File has been created successfully in appropriate folder, then scheduler will send the file ahead to legacy system.
4. Additionally ECCOK file will be created on PI Application server which in turn notifies scheduler about the file creation.
5. If processing fails in PI then PIFAIL file will be created on PI application server and the Jobs will end at this point.

Implementation Scenarios:

1. In order to generate ECCOK file for file inbound scenarios, we make use of Operating system commands option that is available in receiver file communication channels. In this case once the message processing is completed (File is generated in the target folder), then ECCOK file will be created using the Shell script as shown below. In this case a dummy file is placed in appropriate folder and as soon as message has been processed successfully, dummy file is copied to create ECCOK file using copy command in the shell script. Use following command in "Run Operating System Command After Message Processing" in receiver communication channel:

sh <Path/Script name.sh> <Path/Sourcefilename> <path/destinationFileName>

An Example for command line can be: sh /In/CopyScript.sh /In/Dummy.txt /In/ ECC

The shell script code to generate ECC OK file is as given below. Example of the file name generated using above script is ECC_120718_OK

2. In case outbound file interface, once the file is picked up, the data can be sent to ECC system via server proxy. Within server proxy a function module can be called for posting the data into ECC system. So if the function module has successfully updated the Data in then ECCOK file can be generated on application server. If data is not posted successfully then function module can return appropriate return codes to generate ECCFAIL file. Sample code for implementing above scenario is as shown below:

DATA: filename       TYPE string.

CALL FUNCTION 'Z_FXNMODULE'

   EXPORTING

         x_input  = input

   EXCEPTIONS

         data_error = 1.

    IF sy-subrc EQ '1'.

    filename = '/In/ECC'. " File name along with file path.

   CONCATENATE  filename '_' sy-datum sy-uzeit '_FAIL' INTO filename.

     OPEN DATASET filename FOR OUTPUT IN TEXT MODE ENCODING DEFAULT.

     CLOSE DATASET filename.

   ELSEIF sy-subrc IS INITIAL.

         filename = '/In/ECC'.      " File name along with file path.

        CONCATENATE  filename '_' sy-datum sy-uzeit '_OK' INTO filename.

      OPEN DATASET filename FOR OUTPUT IN TEXT MODE ENCODING DEFAULT.

      CLOSE DATASET filename.

   ENDIF.

3. In order to generate PIFAIL file, we can implement BADI ALERT_EXIT in SAP PI System.Standard Alert Management only allows notifying a particular recipient regarding failure of the interface via emails. It does not generate any status files that will notify file scheduler about the interface failure. So in order to generate status files from Alerts we will implement BADI ALERT_EXIT and use method MODIFY_LONG_TEXT to generate status files. Steps to implement BADI are mentioned below.

BADI Implementation:

In order to generate status files BADI ‘ALERT_EXIT’ is implemented in PI server with name say ‘ZALERT_EXIT’. This BADI is called every time an alert is raised in system. This BADI implementation uses Alert Category as a filter so that the BADI is called for configured alert category only. In this case category CUSTOMALERTS is used.

1. Go to T-code SE18 to view BADI ‘ALERT_EXIT’: As highlighted below we will utilize method MODIFY_LONG_TEXT to generate status files from the alerts.

2. Go to Menu--> Implementation --> create  to create new implementation for BADI ALERT_EXIT

3. Give appropriate Implementation name. Provide alert category to be used as filter as shown below:

4. Click on Interface tab and then double click on MODIFY_LONG_TEXT to add appropriate ABAP code to generate status files:

5. Following is the ABAP CODE logic of Method ‘MODIFY_LONG_TEXT’:

The entire alert long text is passed in this method as input parameter. This long text is maintained in Alert Category with all required container elements.

In the logic two main elements are used ‘SXMS_RULE_NAME’ and ‘SXMS_ERROR_CODE’.

SXMS_RULE_NAME is the description of Alert Rule we maintain for each interface. A fixed pattern was decided for this description so that we can derive interface Business Area and Interface Id from it.

SXMS_ERROR_CODE is the code of the error and based on this error code we decide what exact is the error and what should be the status file name.

Only sample ABAP code for generating 'PIFAIL' file is provided below. The complete ABAP code developed for our implementation is out of scope of this blog.

DATA: filename       TYPE string.

filename = '/In/PIFAIL'. " Filename consist of file path and actual file name

CONCATENATE  filename '_' sy-datum  INTO filename.

OPEN DATASET filename FOR OUTPUT IN TEXT MODE ENCODING DEFAULT.

CLOSE DATASET filename.

Alert Configuration:

We have created alert category CUSTOMALERTS, which will be used as filter while implementing BADI ALERT_EXIT as shown above.

Container variable used are as follows:

Alert Message title & Short text is:

Long text for alert is:

Error occured while interface execution

Details of error:

Message id for error message is: &SXMS_MSG_GUID&

Sender system is: &SXMS_FROM_SERVICE&

Sender interface  is: &SXMS_FROM_INTERFACE&

Receiver system is:&SXMS_TO_SERVICE&

Error text is: &SXMS_TO_ADAPTER_ERRLINES[]&

Technical Information:

Alert Rule is : &SXMS_RULE_NAME&

Error Code is : &SXMS_ERROR_CODE&

Points to be considered:

1. This approach is tested with Control-M scheduler only. Perhaps the design might need to be enhanced a bit to make it work with other schedulers.
2. This approach was only considered for FILE adapter. However any asynchronous adapter should work fine with this approach. For Synchronous scenario you need not to have this mechanism.
3. Alert User ID used to raise alerts  must have S_DATASET authority object and write permission to create status files in the designated folder.
4. This approach is tested in SAP PI 7.11 system. However this approach will also work for DUAL stack SAP PI 7.3 as Alert framework still exists within ABAP stack in 7.3.