Background:

The support activities in PI and ECC servers ensure that they have to be repeated in an hourly basis in Production Environments. For any kind of errors, the support team has to follow up with other teams for resolving them. The major activities can be grouped into 2 categories based on the server it is performed:

ECC Monitoring activities:

• Crucial Jobs Monitoring – Jobs which are critical in processing/ triggering inbound/outbound idocs or files.
• Idoc Monitoring – Stuck and Error Inbound and Outbound Idocs
• SMQ1 Monitoring  – Ourbound Queue monitoring
• SMQ2 Monitoring – Inbound Queue monitoring
• SM58 tRFC monitoring
• Integration Engine (SXMB_MONI) on ECC monitoring for failed/error messages

PI Monitoring Activities:

• Integration Engine (SXMB_MONI) monitoring for any failed/error/holding messages.
• Message Monitoring and communication channel monitoring in Runtime Workbench.
• Monitoring Business Process Engine using SXMB_MONI_BPE
• Monitoring Runtime Cache in PI.
• SMQ1 Monitoring  – Ourbound Queue monitoring
• SMQ2 Monitoring – Inbound Queue monitoring
• SM58 tRFC monitoring

These activities (that are in ABAP Stack) can be made automated and the result can be consolidated into a report format and mailed to each support team members in an hourly basis. This can be done by writing a custom ABAP Report Program that has to be scheduled as a background job every hour. It helps to point out any error in ECC and PI by checking on the status reflected in the Output Report of the program.

  This custom report is developed to automate the monitoring activities performed in ECC and PI. This program runs in background as a scheduled job and the Job is scheduled to run for every hour. The output of this program is a report (document) which is stored in a spool (A spool request is a document for which a print function has been selected. The spool system uses a spool request to store the print data temporarily and to access it). This program also sends an email to the users who ids are set up in the variant of the program. The job also has the ability to run manually, such that the report is displayed on the screen.

How it works?

The report is generated based on the crucial activities performed in monitoring. In the report, the results for these activities by default, is having 2 status: Success (for no errors) and Failure (For any errors). In case of failure, the error details are also mentioned in subsequent lines in the report.

ECC

SMQ1 Monitoring 

Outbound Queue Destination           _____ to _____

SMQ2 Monitoring

Inbound Queue Destination             _____ to _____

SM58

RFC Destination                            _____ to _____

Job Monitoring

Jobs                                             _____ to _____          

IDOC Monitoring

Status                                          _____ to _____

SXMB_MONI

Status Group                                _____ to _____

PI

SMQ1 Monitoring 

Outbound Queue Destination           _____ to _____

SMQ2 Monitoring

Inbound Queue Destination             _____ to _____                                  

SXMB_MONI

Status Group                                 _____ to _____

SM58

RFC Destination                            _____ to _____

Basic Steps:

The ABAP program uses 2 Function Modules, one of them is written in ECC server and the other one in PI Server. The program calls the Function Module in PI by setting up an RFC.

• Function module within ECC performs all checks within in ECC as specified by the import parameters in the function module. At the end of execution, it returns the values back to the main program.

• Function module in PI performs all checks in ABAP stack of PI as specified by the import parameters in the function module. At the end of execution, it returns the values back to the main program.

The Report Program calls these 2 function modules and then writes them as a single report and mails the same report to intended recipients.

Point to note: RFC connection must exist between systems that require monitoring. A separate function module needs to be used, which can record the last running time of the program in each run, so that it can trigger itself in an hourly basis from that last run time.

Flow inside the program:

Execution of Function Module inside ECC:

The function module executes multiple activities that are called through forms. These are:

• smq1 monitoring which executes to check the qstate (Queue status) from the table trfcqout pointing to a logical destination
• smq2 monitoring which executes to check the qstate (Queue status) from the table trfcqin pointing to a logical destination
• sm58 monitoring executes same as queue monitoring but validates based on table ARFCSSTATE.
• Job monitoring: This will pull the Job name, start time and start date from a database view, validates the Job status and appends in the output report.
• Idoc monitoring executes to check if any inbound and outbound idocs are in failed state or which are struck. The data is pulled from EDIDC table based on the idoc status and are shown as a list format.
• SXMB_MONI which calls FM SXMB_GET_STATUS_LIST. This function module returns the message status (XI and WS) for the status type which is given in IM_STAT_TYPE or the mdt status which is given in IM_MDT_STATUS. If none is supplied, the whole list of status is returned. If both are supplied, nothing is returned. This status types are used in transaction SXI_MONITOR for selecting a status group.

For monitoring Integration Engine, the following status group are used for effective monitoring:

3    ->      Scheduled

1     ->     Processed Successfully

4     ->     Errors

6     ->     System Error

5     ->     Application Error

Based on the values maintained in the variant of the report program, the appropriate messages can be monitored in an hourly basis.

Execution of Function Module inside PI:

This Function Module resides in PI and before calling this module, the ABAP program sets the RFC system where the Function Module should execute. Based on the input parameters this Function Module first validates between and end date and end time of the program execution and then it performs or calls sub-routines to perform the execution of each and every transaction. Before this it will call a sub-routine which helps in getting the system details and appends to the output report.

The following Forms are executed to get the status of different transactions which are mentioned below. (Implementations same as discussed above)

•          smq1 monitoring

•          smq2 monitoring

•          Idoc monitoring

•          SXMB_MONI monitoring

Variant used:

The variant is the most crucial part for this program and it is the user’s choice to define what sets of values he needs in the report. For example, a report may only gives the messages failed in SXMB_MONI which have errors, in that case, the value for status group 4 has to be maintained inside the variant. Similarly in ECC, the Idoc Monitoring can be defined based on the status maintained in the variant. An example for such instance is shown in below screenshot:

Output Report shown as as example:

ECC Job Monitoring Report:

The ECC Job Monitoring Report shows the status for various crucial jobs which are used in Idoc/File Processing, the associated program names as well as the variant details (whether they have run successfully or got cancelled) and also the tRFC connections, Inbound and Outbound Queues status in the single report.

Stuck Idoc Monitoring:

This part of the report contains the hourly counts of Stuck Idocs (with status 30 and 64) for various message types. The counts are denoted in the number column. A separate table (Z Table) is also used where the team and the sub team details for various message types and partners are maintained and the function module while giving the idoc counts based on message types and partner nos, also looks up that table simultaneously to give the Owner Functional Team (Tm) and the Sub team (STm) details in the report as well.

Error Idocs monitoring:

This part of the report contains the hourly counts of Error Idocs (with status 52, 29,17,26, 56, 51, 02 ) for various message types.Here instead of idoc counts, the idoc numbers itself are reflected in the report. Also the concept of Team and Sub Team details and the internal functionality is implemented in the same way like that used in Stuck Idocs.

PI Monitoring:

In PI part, the only difference is that, SXMB_MONI Transaction is internally called with the hourly messages having status maintained in status group. If the status group is chosen only as error, the error messages are listed with all the relevant details like message IDs, date, time, namespace, sender interface name, sender system, receiver system, etc.

Additional Function Modules used for printing and mailing the report:

Although, it is totally based on requirements, but the overall report can be used in the following ways using separate Function Modules created inside ECC.

• To Print the overall report using a spool request.
• To Mail the overall report (using SMTP ABAP email development structure) separately every hour to the intended recipients who can use it as a consolidated log to monitor overall status of the systems.