Introduction: AIF Extendibility
AIF (Application Interface Framework) offers dashboard functionality for monitoring interfaces for those interfaces defined and setup in AIF in the target ECC Instance. The dashboard consists of views to see the summary, details, data structure and data content components with easy navigations. However, the scope of the visibility is within the ECC instance AIF is installed. For example, there is no visibility to middleware portion of the message delivery, if the message is coming through a middleware like SAP PO (single stack). Typically, the message monitoring of the middleware portion can only be viewed from the SAP PO itself with a web interface, and to do that, it should be accessed through appropriate accounts defined in SAP PO. Even if a message is viewed in this way, the correlation to the AIF interface is not apparently visible and it has to be manually explored to find out the correlation.
In this blog, the goal is to extend the standard dashboard with extra functionality to make monitoring more integrated and if necessary, a troubleshooting of a problem can be explored without having to leave AIF dashboard session. Example scenario in this case will be implemented on following platforms:
In this environment, typical inbound messages to ECC are coming from SAP PO triggered by the partners. AIF is configured to receive inbound messages and process them. Both IDOC and ABAP Proxy interfaces are configured. AIF will alert if messages incoming has any inconsistency or errors at SAP Processing.
The dashboard would show the inbound messages with errors, but only can view the transformed message from SAP PO. If the user needs to see the original message for input value for a certain field, he has to ask help for SAP PO Monitoring. We are going to implement an extension to show message details linking the AIF message to SAP PO message and use SAP PO Provided list of APIs to retrieve and manipulate the data in ECC.
As a complementary function, we also develop another extension to see the Message Status overview from SAP PO.
We also add another extension to provide PIMON Browser functionality to be able to login to SAP PO and view the related message details in browser mode.
Design Approach
As a first step, the following ABAP programs will be developed in ECC.
This program has following processes:
This program uses HTTP calls to find out message status view from SAP PO.
This program brings the browser panel to view message monitoring by way of regularly login in to SAP PO system.
Finally, these features are added to AIF in the view 1 (Message View) of the Dashboard as 3 buttons to invoke the 3 programs listed above.
Design:
Let’s discuss the AIF extension first.
In AIF, there is one enhancement BADI called EI_AIF_V1_ACT, which allows to add extra buttons in the dashboard views and to code the actions for those buttons.
We are going to use the view 1 (Message View) for the additional buttons and then code the actions.
The screenshot shows the implemented enhancement and the methods involved.
GET_FUNC_LIST – The added 3 buttons (ZPOMON, ZPOMO2 and ZPOMO3) coded here:
DO_ACTION has the following code to execute the respective button actions:
We will be building 3 independent programs to actually do the bulk of work in getting PO message data and manipulating and presenting them.
The program inputs like selection screen options and parameters should be built and passed to the programs. The logic prior to submit above programs, is coded to achieve this. In particular the date/time selection is required to the PO Message Status view, and the message GUID is used to determine the type of interface IDOC or non-IDOC. The following is the code developed for this enhancement.
AIF Dashboard Screen with added buttons for extra functionality:
AIF Related activities are complete by this step.
ABAP Development
Next part of the design is to develop 3 independent programs, YPO_MONI_MSG, Y_PO_MSG_OVERVIEW and Y_HTML_VIEWER.
Basis for Message Monitoring (YPO_MONI_MSG)
Single Stack SAP PO:
Started with NetWeaver version 7.3, SAP PO equipped with only the Java Stack . Since it is detached from ABAP stack, there is no transaction SXMB_IFR to re-direct to Web Based user interface to monitor activities. So a separate login process required to access the Java Web Interface.
SAP has offered a set of APIs for monitoring, and those API can be converted to SOAP calls.
Here is the link for those Web Services:
http://<host:port>/AdapterMessageMonitoring/basic?wsdl=binding&style=document
This is a portion of the list, if we use the WS Navigator to expand the services available:
There are 5 services useful for building client services from ECC.
Supply a list of messages
Given message id, it lists the messages.
Given message keys, it lists the messages
Returns the payload string for a given message key
Returns the payload string for a given message key and version number
Method of integration:
We can either build SAP PO interfaces and create ABAP Proxy in ECC to run these services. The disadvantage is that it then uses POs valuable interface running threads. Also it will be redundant from SAP PO perspective. Instead the SOA Manager in ECC can be used to integrate with SAP PO point-to-point for monitoring services.
There are 2 main steps involved in this as configuration and development.
Illustrated and explained below are the how to steps:
Select Enterprise Services->Client Proxies, from transaction SE80 to create Client Proxy:
Select source “Local File” and continue:
From the local file browser select the saved WSDL file and continue:
In here I have entered the local package and prefix Y, and checked the Local Object. It is open to other appropriate choices. Continue to the next step:
The process is complete. As mentioned after taking the “Complete” option, save the objects and activate it.
Save and activate:
Once the client proxies are active, we can see all the services have been created in ABAP.
SOAManager configuration steps are explained below:
Enter transaction SOAManager in ECC client to display the web screen:
Take second tab: Application and Scenario Communication:
Take option Single Service Administration:
Select “Consumer Proxy” from Search By, and enter YPO*MON* in the search pattern and “Both Names” from Field option and click “Go” button.
This line should show the client proxy built using SE80.
Highlight the line and click Apply Selection button:
Create Logical Port:
Give an appropriate port name (eg. LP_PO) with a description, and select Manual configuration. Make sure “Logical port Default” checked.
Enter SAP PO login user name and the password. Usually this would be a service user id to access SAP PO when API’s are called from ECC.
Go to the Transport settings Tab:
Typical entries should look like below:
Save the configuration, and it should generate an RFC connection of type HTTP External in ECC.
In Additional Information Tab:
HTTP destination can be found, and it will be a Hexadecimal string.
There are enough Documentation related to SOAManager configuration of this kind in SAP Community, you can Google and search if you run in to issues.
Once the RFC (HTTP Destination) is generated, you can test the connectivity from SM59 to make sure it works.
Y_PO_MONI_MSG Program logic:
The services created by SE80 client proxy step, are the basis to build the logic around.
First it retrieves a list of messages per criteria entered on selection screen using GET_MESSAGE_LIST. An important step in the criteria is to correlate the message in AIF to SAP PO Payload. This is achieved with Message GUID in AIF which is the same for SAP PO message. It will be 16 character Hexadecimal string in ABAP Proxy and IDOC number in IDOC interfaces. In case of IDOC, the actual GUID is stored in the IDOC Record. There is logic to get the GUID from the IDOC Record.
Then it allows drilling down to the details of individual messages either by KEY or ID. In the program the 2 requests GET_MESSAGE_BYTES_JAVA_LANG_ST and GET_MESSAGE_BYTES_JAVA_LANG_S1 have been called to retrieve the payload, where the first API could be used to retrieve versions of messages, for example, version of message prior to the mapping step.
The XML (or non-XML in some cases) payload in the retrieved messaged is enveloped with headers and trailers, and therefore the real message needs to be extracted out of it.
The program uses common search to locate the XML payload, and then uses some XML tools available in ABAP to form it in correct format before it is presented to the display.
As mentioned, the payload could be non-XML, which has to be taken into consideration. Another possible issue with payload is the size which could lead to performance issues while attempting to put on display. The program takes care of this issue by restricting display to a given maximum size limit for the display, and if the size happens to exceed the limit, then offering to save the payload in local directory.
As mentioned, when the versions (pre-mapping and post-mapping ) are retrieved, the program offers to show in split screen to see data in both versions. This helps to identify source issues or transformation issues in case of troubleshooting for an error message in a validation of a downstream step, for example.
The program uses standard ABAP class CL_GUI_XML_EDITOR to present split screen display of payload XML versions. CL_GUI_XML_EDITOR offers features like display the XML in grid view and ability to collapse nodes, and easy navigation over the nodes etc.
Part of the codes listed here:
Message Overview Functionality (YPO_MSG_OVERVIEW):
This corresponds to the Message Status Overview display in standard PO Monitoring. The filtering is required to make it daily, weekly, monthly or yearly retrieval of the message status, as to see success and failed messages over a period of time.
The program calculates the period by taking the dates on AIF selection screen. Once the period is determined, it does a HTTP POST call to retrieve the period data first. Then in a second HTTP POST it retrieves the messages status for the period just retrieved from the previous request.
A HTTP destination can be defined externally or built dynamically for the connection providing URL, credentials etc.
We will be using the function module HTTP_POST in the code. It requires the absolute URI, RFC Destination or Implicit coding of credentials. The example here used the latter approach with dynamic connection. The user id and password should be scrambled to input into the function call.
The XML responses retrieved are parsed by standard ABAP tools, and derives the data to use in follow-up requests and display on screen in grid view.
The program also offers an option to display status as a Pie Chart, for the selected lines of message status view. It helps to see it visually the proportion of failures or successes of the messages selectively or globally over a period of time.
HTTP Post:
Main Program Screenshots:
Find Periods Routine:
Access to SAP PO Monitoring over Browser (Y_HTML_VIEWER):
This functionality is added to complete the full functionality of monitoring along with the previously explained features. For example, if a particular message is a focus for the troubleshooting, this feature allows to pick that message displayed in standard SAP PO Monitoring on browser. The importance is to pass the message id (key) in that browser functionality. Also this needs login to the SAP PO Instance, therefore requires an account in SAP PO UME.
The program uses the standard ABAP class CL_HTML_VIEWER to implement this functionality. Once it shows up the first browser screen of the message status display, the usual navigation allows to drill down the message depending on the user’s permissions restricted by security roles.
With that the code and the configuration are complete and the functionality can be tested by now.
Below are the navigation screens to show the functionality and the results:
How to navigate with AIF Dashboard functionality:
Additional Buttons in View 1 of the Dashboard:
Select Message and go to SAP PO to see the details:
PO Message Details:
Source Payload in XML:
Target Payload in XML (IDOC):
Go to Source / Target Split Screen:
Split Screen with Source in the left and Target in the right – Structured Format:
Split Screen : Switch to XML View:
Split Screen : XML View:
2. Message Overview in SAP PO for the selected Period daily, monthly or yearly:
Message Overview:
See graphical statistics
Pie Chart:
Select a subset of interfaces:
Pie-Chart
3. Access to SAP PO Web View:
Select a Message and navigate:
SAP PO Login:
SAP PO Message Details:
Navigation to view payload:
Conclusion:
The purpose of this blog is how to address the scope of visibility of an integration from end to end. We have seen this issue in many integration projects, the user has to rely on multiple teams of experts to troubleshoot an issue, because of non-visibility. There could be valid reasons like parts of integrations running in different platforms and security issues restricting access to those platforms. Also it could be a training issue as well.
AIF is a platform for the user to troubleshoot issues without reaching out to the technical experts. Sometimes they need expert support in case of critical technical issue, that is not related to business process. But if a user wants to see a data coming from a partner as it is, that will be a great help to arrive at a quick resolution.
AIF (Application Interface Framework) offers dashboard functionality for monitoring interfaces for those interfaces defined and setup in AIF in the target ECC Instance. The dashboard consists of views to see the summary, details, data structure and data content components with easy navigations. However, the scope of the visibility is within the ECC instance AIF is installed. For example, there is no visibility to middleware portion of the message delivery, if the message is coming through a middleware like SAP PO (single stack). Typically, the message monitoring of the middleware portion can only be viewed from the SAP PO itself with a web interface, and to do that, it should be accessed through appropriate accounts defined in SAP PO. Even if a message is viewed in this way, the correlation to the AIF interface is not apparently visible and it has to be manually explored to find out the correlation.
In this blog, the goal is to extend the standard dashboard with extra functionality to make monitoring more integrated and if necessary, a troubleshooting of a problem can be explored without having to leave AIF dashboard session. Example scenario in this case will be implemented on following platforms:
- AIF Release 702 Level 0003 (SAPK-70203INAIF)
- ECC 6.0 Basis Release 701 Level 0005 (SAPKB70105)
- SAP Process Orchestration (PO) 7.4 (Single Stack)
In this environment, typical inbound messages to ECC are coming from SAP PO triggered by the partners. AIF is configured to receive inbound messages and process them. Both IDOC and ABAP Proxy interfaces are configured. AIF will alert if messages incoming has any inconsistency or errors at SAP Processing.
The dashboard would show the inbound messages with errors, but only can view the transformed message from SAP PO. If the user needs to see the original message for input value for a certain field, he has to ask help for SAP PO Monitoring. We are going to implement an extension to show message details linking the AIF message to SAP PO message and use SAP PO Provided list of APIs to retrieve and manipulate the data in ECC.
As a complementary function, we also develop another extension to see the Message Status overview from SAP PO.
We also add another extension to provide PIMON Browser functionality to be able to login to SAP PO and view the related message details in browser mode.
Design Approach
As a first step, the following ABAP programs will be developed in ECC.
- YPO_MONI_MSG
- Y_PO_MSG_OVERVIEW
- Y_HTML_VIEWER
- YPO_MONI_MSG
This program has following processes:
- Get the filtering requests from the selection screens and parameters
- Pass filtering and call getMessageList()
- The response which is a list of messages is presented on ALV Grid
- Based on ALV grid selection, it brings individual message payloads
- Message payloads are presented in XML on POP UP screens
- If a line is selected and compare button is clicked, it presents a split screen for version comparison of the source and target payloads as tabular or XML structures
- Y_PO_MSG_OVERVIEW
This program uses HTTP calls to find out message status view from SAP PO.
- Gets the message status periods (daily, weekly, monthly, yearly).
- With the period, it makes a request to bring the message status in that period.
- Shows in ALV Grid the Message Status
- Option to display the status as a Pie Chart in graphic mode
- Y_HTML_VIEWER
This program brings the browser panel to view message monitoring by way of regularly login in to SAP PO system.
- Login to SAP PO
- “PIMON” functionality with navigation
Finally, these features are added to AIF in the view 1 (Message View) of the Dashboard as 3 buttons to invoke the 3 programs listed above.
Design:
Let’s discuss the AIF extension first.
In AIF, there is one enhancement BADI called EI_AIF_V1_ACT, which allows to add extra buttons in the dashboard views and to code the actions for those buttons.
We are going to use the view 1 (Message View) for the additional buttons and then code the actions.
The screenshot shows the implemented enhancement and the methods involved.
GET_FUNC_LIST – The added 3 buttons (ZPOMON, ZPOMO2 and ZPOMO3) coded here:
DO_ACTION has the following code to execute the respective button actions:
We will be building 3 independent programs to actually do the bulk of work in getting PO message data and manipulating and presenting them.
- YPO_MONI_MSG (ZPOMON)
- Y_PO_MSG_OVERVIEW (ZPOMO2)
- Y_HTML_VIEWER (ZPOMO3)
The program inputs like selection screen options and parameters should be built and passed to the programs. The logic prior to submit above programs, is coded to achieve this. In particular the date/time selection is required to the PO Message Status view, and the message GUID is used to determine the type of interface IDOC or non-IDOC. The following is the code developed for this enhancement.
METHOD /AIF/IF_V1_ACT~DO_ACTION.
TYPES: begin of ty_idoc_key,
docnum type edidc-docnum,
arckey TYPE edidc-arckey,
end of ty_idoc_key.
data: lv_fname(50) VALUE '(/AIF/ERROR_HANDLING_TRANS)S_MDATE',
*Selection screen parameter located in (/AIF/ERROR_HANDLING_TRANS)
lv_rcvr TYPE /SAPTRX/TEXT20,
ls_msg_data TYPE /AIF/TREENODE_ST,
lt_msgid type RANGE OF SXMS_WP-info,
ls_msgid like LINE OF lt_msgid,
lt_inmsp TYPE RANGE OF SXMS_WP-info,
ls_inmsp LIKE LINE OF lt_inmsp,
lv_proxy(1) VALUE ' ',
lt_idocid type RANGE OF SXMS_WP-info,
ls_idocid like LINE OF lt_msgid.
data: lt_idockey TYPE TABLE OF ty_idoc_key,
ls_idockey type ty_idoc_key.
FIELD-SYMBOLS: <fs_date> type date_range,
<fs_time> TYPE BAPI_EMMA_TIME_RANGE,
<fs_appl> TYPE any.
ASSIGN (lv_fname) to <fs_date>. “Date picked from sel screen
lv_fname+27 = 'S_MTIME'.
ASSIGN (lv_fname) to <fs_time>. “Time picked from sel screen
lv_fname+27 = 'P_APPL'.
assign (lv_fname) to <fs_appl>.
loop at it_msg_data INTO ls_msg_data.
if ls_msg_data-msgguid co '0123456789 '. “IDOC type
ls_idocid-low = ls_msg_data-msgguid.
ls_idocid-option = 'EQ'.
ls_idocid-sign = 'I'.
append ls_idocid to lt_idocid.
else. “non-IDOC
ls_msgid-low = ls_msg_data-msgguid.
ls_msgid-option = 'EQ'.
ls_msgid-sign = 'I'.
append ls_msgid to lt_msgid.
ENDIF.
ENDLOOP.
if lt_idocid[] is not INITIAL.
select docnum
arckey
into table lt_idockey
from edidc
where docnum in lt_idocid.
loop at lt_idockey INTO ls_idockey.
CONDENSE ls_idockey-arckey.
ls_msgid-low = ls_idockey-arckey.
ls_msgid-option = 'EQ'.
ls_msgid-sign = 'I'.
append ls_msgid to lt_msgid.
ENDLOOP.
endif.
case iv_func_code.
when 'ZPOMON'. “YPO_MSG_MONI
submit YPO_MONI_MSG
with s_msgid in lt_msgid
with p_stdat = <fs_date>-low
WITH p_sttim = <fs_time>-low
with p_endat = <fs_date>-high
with p_entim = <fs_time>-high
with p_rcvr = lv_rcvr
AND RETURN.
when 'ZPOMO2'. “Y_PO_MSG_OVERVIEW
if <fs_date>-option eq 'EQ'. “Daily message status
submit Y_PO_MSG_OVERVIEW
with p_daily = 'X'
with p_yrly = ' '
with p_mthly = ' '
with p_wkly = ' '
with p_date = <fs_date>-low
AND RETURN.
elseif <fs_date>-option eq 'BT'. “Yearly message status
if <fs_date>-high+4(4) eq '1231'.
submit Y_PO_MSG_OVERVIEW
with p_daily = ' '
with p_yrly = 'X'
with p_mthly = ' '
with p_wkly = ' '
with p_date = <fs_date>-low
AND RETURN.
else.
submit Y_PO_MSG_OVERVIEW “Monthly message status
with p_daily = ' '
with p_yrly = ' '
with p_wkly = ' '
with p_mthly = 'X'
with p_date = <fs_date>-low
AND RETURN.
endif.
else.
submit Y_PO_MSG_OVERVIEW “Default to yearly
with p_daily = ' '
with p_yrly = 'X'
with p_wkly = ' '
with p_mthly = ' '
with p_date = syst-datlo
AND RETURN.
ENDIF.
when 'ZPOMO3'. “Y_HTML_VIEWER
clear ls_msgid.
read table lt_msgid INTO ls_msgid index 1.
submit Y_HTML_VIEWER
with p_msgid = ls_msgid-low
AND RETURN.
ENDCASE.
ENDMETHOD.
AIF Dashboard Screen with added buttons for extra functionality:
AIF Related activities are complete by this step.
ABAP Development
Next part of the design is to develop 3 independent programs, YPO_MONI_MSG, Y_PO_MSG_OVERVIEW and Y_HTML_VIEWER.
Basis for Message Monitoring (YPO_MONI_MSG)
Single Stack SAP PO:
Started with NetWeaver version 7.3, SAP PO equipped with only the Java Stack . Since it is detached from ABAP stack, there is no transaction SXMB_IFR to re-direct to Web Based user interface to monitor activities. So a separate login process required to access the Java Web Interface.
SAP has offered a set of APIs for monitoring, and those API can be converted to SOAP calls.
Here is the link for those Web Services:
http://<host:port>/AdapterMessageMonitoring/basic?wsdl=binding&style=document
This is a portion of the list, if we use the WS Navigator to expand the services available:
There are 5 services useful for building client services from ECC.
- getMessageList
Supply a list of messages
- getMessageByIDs
Given message id, it lists the messages.
- getMessageByKeys
Given message keys, it lists the messages
- getMessageBytesJavaLangStringBoolean
Returns the payload string for a given message key
- getMessageBytesJavaLangStringIntBoolean
Returns the payload string for a given message key and version number
Method of integration:
We can either build SAP PO interfaces and create ABAP Proxy in ECC to run these services. The disadvantage is that it then uses POs valuable interface running threads. Also it will be redundant from SAP PO perspective. Instead the SOA Manager in ECC can be used to integrate with SAP PO point-to-point for monitoring services.
There are 2 main steps involved in this as configuration and development.
- ABAP Code development for a client proxy
- SOAManager configuration for establishing the SAP PO Connectivity (Port setup)
Illustrated and explained below are the how to steps:
Select Enterprise Services->Client Proxies, from transaction SE80 to create Client Proxy:
Select source “Local File” and continue:
From the local file browser select the saved WSDL file and continue:
In here I have entered the local package and prefix Y, and checked the Local Object. It is open to other appropriate choices. Continue to the next step:
The process is complete. As mentioned after taking the “Complete” option, save the objects and activate it.
Save and activate:
Once the client proxies are active, we can see all the services have been created in ABAP.
SOAManager configuration steps are explained below:
Enter transaction SOAManager in ECC client to display the web screen:
Take second tab: Application and Scenario Communication:
Take option Single Service Administration:
Select “Consumer Proxy” from Search By, and enter YPO*MON* in the search pattern and “Both Names” from Field option and click “Go” button.
This line should show the client proxy built using SE80.
Highlight the line and click Apply Selection button:
Create Logical Port:
Give an appropriate port name (eg. LP_PO) with a description, and select Manual configuration. Make sure “Logical port Default” checked.
Enter SAP PO login user name and the password. Usually this would be a service user id to access SAP PO when API’s are called from ECC.
Go to the Transport settings Tab:
Typical entries should look like below:
Save the configuration, and it should generate an RFC connection of type HTTP External in ECC.
In Additional Information Tab:
HTTP destination can be found, and it will be a Hexadecimal string.
There are enough Documentation related to SOAManager configuration of this kind in SAP Community, you can Google and search if you run in to issues.
Once the RFC (HTTP Destination) is generated, you can test the connectivity from SM59 to make sure it works.
Y_PO_MONI_MSG Program logic:
The services created by SE80 client proxy step, are the basis to build the logic around.
First it retrieves a list of messages per criteria entered on selection screen using GET_MESSAGE_LIST. An important step in the criteria is to correlate the message in AIF to SAP PO Payload. This is achieved with Message GUID in AIF which is the same for SAP PO message. It will be 16 character Hexadecimal string in ABAP Proxy and IDOC number in IDOC interfaces. In case of IDOC, the actual GUID is stored in the IDOC Record. There is logic to get the GUID from the IDOC Record.
Then it allows drilling down to the details of individual messages either by KEY or ID. In the program the 2 requests GET_MESSAGE_BYTES_JAVA_LANG_ST and GET_MESSAGE_BYTES_JAVA_LANG_S1 have been called to retrieve the payload, where the first API could be used to retrieve versions of messages, for example, version of message prior to the mapping step.
The XML (or non-XML in some cases) payload in the retrieved messaged is enveloped with headers and trailers, and therefore the real message needs to be extracted out of it.
The program uses common search to locate the XML payload, and then uses some XML tools available in ABAP to form it in correct format before it is presented to the display.
As mentioned, the payload could be non-XML, which has to be taken into consideration. Another possible issue with payload is the size which could lead to performance issues while attempting to put on display. The program takes care of this issue by restricting display to a given maximum size limit for the display, and if the size happens to exceed the limit, then offering to save the payload in local directory.
As mentioned, when the versions (pre-mapping and post-mapping ) are retrieved, the program offers to show in split screen to see data in both versions. This helps to identify source issues or transformation issues in case of troubleshooting for an error message in a validation of a downstream step, for example.
The program uses standard ABAP class CL_GUI_XML_EDITOR to present split screen display of payload XML versions. CL_GUI_XML_EDITOR offers features like display the XML in grid view and ability to collapse nodes, and easy navigation over the nodes etc.
Part of the codes listed here:
- Message List Retrieval:
METHOD retrieve_messages.
CONSTANTS: lc_status TYPE stat5 VALUE 'P'.
CLEAR: ls_output, gt_afw, gt_afw[].
CALL METHOD YPO_MON_MSG->GET_MESSAGE_LIST
EXPORTING
INPUT = ls_input
IMPORTING
OUTPUT = ls_output.
lv_tzone = 'CST'.
clear ls_afw.
loop at ls_output-response-list-adapter_framework_data into ls_afw_source.
ls_afw-count = ls_afw-count + 1.
*Code continues…
- Message Content Retrieval:
METHOD get_document_detail.
CONSTANTS: lc_max_file_size type i VALUE '30000'.
data: ls_input type YPO_MON_GET_MESSAGES_BY_IDS_IN,
ls_output TYPE YPO_MON_GET_MESSAGES_BY_IDS_OU,
lt_msgids type YPO_MON_STRING_TAB,
ls_msgids type string.
data: ls_input1 type YPO_MON_GET_MESSAGE_BYTES_JAV3,
ls_output1 TYPE YPO_MON_GET_MESSAGE_BYTES_JAV2,
ls_out_string TYPE string.
DATA: lr_xml_doc TYPE REF TO cl_xml_document.
data: ls_afw TYPE afw_type.
IF column EQ 'MESSAGE_ID'
or column eq 'MESSAGE_KEY'.
CLEAR : ls_afw.
READ TABLE gt_afw INTO ls_afw INDEX row.
IF sy-subrc EQ 0.
case column.
when 'MESSAGE_ID'.
data: ls_input2 TYPE YPO_MON_GET_MESSAGE_BYTES_JAV1,
ls_output2 TYPE YPO_MON_GET_MESSAGE_BYTES_JAVA.
ls_input2-message_key = ls_afw-message_key.
ls_input2-version = 0.
TRY.
CALL METHOD YPO_MON_MSG->GET_MESSAGE_BYTES_JAVA_LANG_ST
EXPORTING
INPUT = ls_input2
IMPORTING
OUTPUT = ls_output2.
payload_present( ls_output2-response ).
CATCH CX_AI_SYSTEM_FAULT .
CATCH YPO_MON_CX_GET_MESSAGE_BYTES_J .
CATCH YPO_MON_CX_GET_MESSAGE_BYTES_1 .
CATCH CX_AI_APPLICATION_FAULT .
ENDTRY.
* else.
when 'MESSAGE_KEY' .
TRY.
ls_input1-message_key = ls_afw-message_key.
CALL METHOD YPO_MON_MSG->GET_MESSAGE_BYTES_JAVA_LANG_S1
EXPORTING
INPUT = ls_input1
IMPORTING
OUTPUT = ls_output1.
payload_present( ls_output1-response ).
CATCH CX_AI_SYSTEM_FAULT .
ENDTRY.
* Add links to functions or transactions to navigate as needed
ENDcase.
ENDIF.
ENDIF.
endmethod. "get_document_detail
- Payload Presenter
METHOD payload_present.
CONSTANTS: lc_max_file_size type i VALUE '30000'.
data: ls_out_string TYPE string.
DATA: lr_xml_doc TYPE REF TO cl_xml_document.
data: lv_header type string,
lv_xml type string,
lv_trailer TYPE string,
lv_rc TYPE SYSUBRC.
call method extract_xml
EXPORTING
rstring = rstring
IMPORTING
xml_string = lv_xml.
data: lv_answer(1),
lv_filename TYPE string,
lv_path TYPE string,
lv_fullpath TYPE string,
lt_xml type TABLE OF string,
lv_strlen TYPE i,
lv_xstrlen TYPE i.
lv_strlen = strlen( lv_xml ).
* lv_xstrlen = xstrlen( lv_xml ).
if lv_strlen gt lc_max_file_size.
CALL FUNCTION 'POPUP_TO_CONFIRM'
EXPORTING
TITLEBAR = 'Payload size is over 30000 bytes'(006)
TEXT_QUESTION = 'Save payload as a local file?'(003)
TEXT_BUTTON_1 = 'Yes'(004)
TEXT_BUTTON_2 = 'No'(005)
IMPORTING
ANSWER = lv_answer
EXCEPTIONS
TEXT_NOT_FOUND = 1
OTHERS = 2
.
if lv_answer eq '1'. "yes
CALL METHOD CL_GUI_FRONTEND_SERVICES=>FILE_SAVE_DIALOG
CHANGING
FILENAME = lv_filename
PATH = lv_path
FULLPATH = lv_fullpath
EXCEPTIONS
CNTL_ERROR = 1
ERROR_NO_GUI = 2
NOT_SUPPORTED_BY_GUI = 3
others = 4
.
IF SY-SUBRC <> 0.
ENDIF.
append lv_xml to lt_xml.
CALL METHOD CL_GUI_FRONTEND_SERVICES=>GUI_DOWNLOAD
EXPORTING
FILENAME = lv_filename
CHANGING
DATA_TAB = lt_xml
EXCEPTIONS
FILE_WRITE_ERROR = 1
NO_BATCH = 2
GUI_REFUSE_FILETRANSFER = 3
INVALID_TYPE = 4
NO_AUTHORITY = 5
UNKNOWN_ERROR = 6
HEADER_NOT_ALLOWED = 7
SEPARATOR_NOT_ALLOWED = 8
FILESIZE_NOT_ALLOWED = 9
HEADER_TOO_LONG = 10
DP_ERROR_CREATE = 11
DP_ERROR_SEND = 12
DP_ERROR_WRITE = 13
UNKNOWN_DP_ERROR = 14
ACCESS_DENIED = 15
DP_OUT_OF_MEMORY = 16
DISK_FULL = 17
DP_TIMEOUT = 18
FILE_NOT_FOUND = 19
DATAPROVIDER_EXCEPTION = 20
CONTROL_FLUSH_ERROR = 21
NOT_SUPPORTED_BY_GUI = 22
ERROR_NO_GUI = 23
others = 24
.
if syst-subrc is INITIAL.
message s999 with 'File downloaded successfully'.
endif.
else.
endif.
* lv_xml = '<big_payload>more than 30000 bytes..</big_payload>'.
else.
create object lr_xml_doc.
CALL METHOD LR_XML_DOC->PARSE_STRING
EXPORTING
STREAM = lv_xml
RECEIVING
RETCODE = lv_rc.
if lv_rc is initial.
CALL METHOD LR_XML_DOC->display.
else.
concatenate '<non_xml_content>' lv_xml '</non_xml_content>' INTO lv_xml.
CALL METHOD LR_XML_DOC->PARSE_STRING
EXPORTING
STREAM = lv_xml
RECEIVING
RETCODE = lv_rc.
if lv_rc is initial.
CALL METHOD LR_XML_DOC->display.
endif.
endif.
endif.
endmethod. "payload_present
- Display split view
METHOD display_split_view.
DATA: lr_xml_doc TYPE REF TO cl_xml_document.
data: lv_header type string,
lv_xml type string,
lv_trailer TYPE string,
lv_rc TYPE SYSUBRC.
create object gr_container
EXPORTING
container_name = 'CUSTOM_CONTAINER'.
CREATE OBJECT lr_SPLITTER
EXPORTING
PARENT = gr_CONTAINER
ROWS = 1
COLUMNS = 2
ALIGN = 15. " (splitter fills the hole custom container)
** get part of splitter container for 1st table
CALL METHOD lr_SPLITTER->GET_CONTAINER
EXPORTING
ROW = 1
COLUMN = 1
RECEIVING
CONTAINER = lr_gc_PARENT1.
CALL METHOD lr_SPLITTER->GET_CONTAINER
EXPORTING
ROW = 1
COLUMN = 2
RECEIVING
CONTAINER = lr_gc_PARENT2.
** Display first ALV
lv_xml = '<test>a</test>'.
data: lv_xxml TYPE xstring,
lv_xxml1 TYPE xstring.
DATA: lr_xml_tree1 TYPE REF TO cl_gui_xml_editor,
lr_xml_tree2 TYPE REF TO cl_gui_xml_editor.
CALL FUNCTION 'HR_KR_STRING_TO_XSTRING'
EXPORTING
UNICODE_STRING = gv_xml_v0
IMPORTING
XSTRING_STREAM = lv_xxml
.
IF SY-SUBRC <> 0.
ENDIF.
lv_xml = '<abc>pqr</abc>'.
CALL FUNCTION 'HR_KR_STRING_TO_XSTRING'
EXPORTING
UNICODE_STRING = gv_xml
IMPORTING
XSTRING_STREAM = lv_xxml1
.
IF SY-SUBRC <> 0.
ENDIF.
CALL METHOD cl_gui_xml_editor=>create
EXPORTING
im_container = lr_gc_parent1
im_xml = lv_xxml
IMPORTING
ex_editor = lr_xml_tree1.
data: lr_properties TYPE REF TO CL_GUI_XML_PROPERTIES.
CALL METHOD cl_gui_xml_editor=>create
EXPORTING
im_container = lr_gc_parent2
im_xml = lv_xxml1
IMPORTING
ex_editor = lr_xml_tree2.
ENDMETHOD. "display_split_view
Message Overview Functionality (YPO_MSG_OVERVIEW):
This corresponds to the Message Status Overview display in standard PO Monitoring. The filtering is required to make it daily, weekly, monthly or yearly retrieval of the message status, as to see success and failed messages over a period of time.
The program calculates the period by taking the dates on AIF selection screen. Once the period is determined, it does a HTTP POST call to retrieve the period data first. Then in a second HTTP POST it retrieves the messages status for the period just retrieved from the previous request.
A HTTP destination can be defined externally or built dynamically for the connection providing URL, credentials etc.
We will be using the function module HTTP_POST in the code. It requires the absolute URI, RFC Destination or Implicit coding of credentials. The example here used the latter approach with dynamic connection. The user id and password should be scrambled to input into the function call.
The XML responses retrieved are parsed by standard ABAP tools, and derives the data to use in follow-up requests and display on screen in grid view.
The program also offers an option to display status as a Pie Chart, for the selected lines of message status view. It helps to see it visually the proportion of failures or successes of the messages selectively or globally over a period of time.
- Part of the Code is here:
form set_credentials.
user = p_user.
pwd = p_pwd.
set extended check off.
len = strlen( user ).
call function 'HTTP_SCRAMBLE'
EXPORTING
source = user
sourcelen = len
key = key
IMPORTING
destination = user.
len = strlen( pwd ).
call function 'HTTP_SCRAMBLE'
EXPORTING
source = pwd
sourcelen = len
key = key
IMPORTING
destination = pwd.
endform.
HTTP Post:
clear: lv_xml_response.
CALL FUNCTION 'HTTP_POST'
EXPORTING
ABSOLUTE_URI = Uri
REQUEST_ENTITY_BODY_LENGTH = 300
USER = user
PASSWORD = pwd
BLANKSTOCRLF = 'X'
IMPORTING
STATUS_CODE = Status_code
STATUS_TEXT = Status_text
RESPONSE_ENTITY_BODY_LENGTH = Len
TABLES
REQUEST_ENTITY_BODY = t_request_body
RESPONSE_ENTITY_BODY = t_response_body
RESPONSE_HEADERS = t_response_header
REQUEST_HEADERS = t_request_header
EXCEPTIONS
CONNECT_FAILED = 1
TIMEOUT = 2
INTERNAL_ERROR = 3
TCPIP_ERROR = 4
SYSTEM_FAILURE = 5
COMMUNICATION_FAILURE = 6
OTHERS = 7.
Main Program Screenshots:
Find Periods Routine:
FORM FIND_PERIODS .
data: lv_date(10),
lv_time(20).
CONCATENATE lv_host_port
'/mdt/messageoverviewqueryservlet?component=' lv_component '&view=' lv_view
into uri.
PERFORM http_post.
perform format_xml.
perform parse_xml.
perform get_periods.
data: lv_dat(10),
lv_freq(1),
lv_found(1).
case 'X'.
when p_yrly.
lv_freq = 'Y'.
when p_daily.
lv_freq = 'D'.
when p_wkly.
lv_freq = 'W'.
when p_mthly.
lv_freq = 'M'.
ENDCASE.
concatenate p_date(4) '-' p_date+4(2) '-' p_date+6(2) INTO lv_dat.
clear: ls_interval, lv_found.
LOOP at lt_interval INTO ls_interval WHERE frequency eq lv_freq.
if lv_dat BETWEEN ls_interval-start_time(10) and ls_interval-end_time(10).
lv_found = 'X'.
exit.
endif.
ENDLOOP.
if lv_found eq 'X'.
gs_range = ls_interval.
SPLIT ls_interval-start_time at space INTO lv_date lv_time.
CONCATENATE lv_date '%20' lv_time INTO ls_interval-start_time.
SPLIT ls_interval-end_time at space INTO lv_date lv_time.
CONCATENATE lv_date '%20' lv_time INTO ls_interval-end_time.
CONCATENATE lv_host_port '/mdt/messageoverviewqueryservlet?component='
lv_component '&view=' lv_view '&begin=' ls_interval-start_time '&end=' ls_interval-end_time INTO uri.
clear:
t_request_body,
t_response_body,
t_response_header,
t_request_header.
PERFORM http_post.
perform filter_response.
perform format_xml.
perform parse_xml.
perform build_view_table.
endif.
ENDFORM. " FIND_PERIODS
Access to SAP PO Monitoring over Browser (Y_HTML_VIEWER):
This functionality is added to complete the full functionality of monitoring along with the previously explained features. For example, if a particular message is a focus for the troubleshooting, this feature allows to pick that message displayed in standard SAP PO Monitoring on browser. The importance is to pass the message id (key) in that browser functionality. Also this needs login to the SAP PO Instance, therefore requires an account in SAP PO UME.
The program uses the standard ABAP class CL_HTML_VIEWER to implement this functionality. Once it shows up the first browser screen of the message status display, the usual navigation allows to drill down the message depending on the user’s permissions restricted by security roles.
- Part of the Code
start-of-selection.
perform select_system.
PERFORM convert_guid.
CONCATENATE lv_host_port lv_url1 gv_msgid lv_url2 INTO gv_url.
call screen 0100.
*&---------------------------------------------------------------------*
*& Module STATUS_0100 OUTPUT
*&---------------------------------------------------------------------*
* text
*----------------------------------------------------------------------*
MODULE STATUS_0100 OUTPUT.
SET PF-STATUS 'STD'.
SET TITLEBAR 'AAA'.
CREATE OBJECT cl_html_container
EXPORTING
container_name = 'WEB_CONTAINER'.
CREATE OBJECT cl_htmlviewer
EXPORTING
parent = cl_html_container.
CALL METHOD cl_htmlviewer->show_url
EXPORTING
url = gv_url.
ENDMODULE
With that the code and the configuration are complete and the functionality can be tested by now.
Below are the navigation screens to show the functionality and the results:
How to navigate with AIF Dashboard functionality:
- Dashboard Transaction - /n/aif/err
Additional Buttons in View 1 of the Dashboard:
Select Message and go to SAP PO to see the details:
PO Message Details:
Source Payload in XML:
Target Payload in XML (IDOC):
Go to Source / Target Split Screen:
Split Screen with Source in the left and Target in the right – Structured Format:
Split Screen : Switch to XML View:
Split Screen : XML View:
2. Message Overview in SAP PO for the selected Period daily, monthly or yearly:
Message Overview:
See graphical statistics
Pie Chart:
Select a subset of interfaces:
Pie-Chart
3. Access to SAP PO Web View:
Select a Message and navigate:
SAP PO Login:
SAP PO Message Details:
Navigation to view payload:
Conclusion:
The purpose of this blog is how to address the scope of visibility of an integration from end to end. We have seen this issue in many integration projects, the user has to rely on multiple teams of experts to troubleshoot an issue, because of non-visibility. There could be valid reasons like parts of integrations running in different platforms and security issues restricting access to those platforms. Also it could be a training issue as well.
AIF is a platform for the user to troubleshoot issues without reaching out to the technical experts. Sometimes they need expert support in case of critical technical issue, that is not related to business process. But if a user wants to see a data coming from a partner as it is, that will be a great help to arrive at a quick resolution.
- SAP Managed Tags:
3 Comments
