Skip to Content

IDoc technology remains one of the commonly used techniques for integrating systems that are running on SAP Application Server ABAP (AS ABAP). In order to monitor processed IDocs in such scenarios, primarily SAP standard monitoring tools – like transactions WE02, WE05 or BD87 – are utilized. All these transactions provide extensive access to all IDoc’s records – control record, segment record and status record. The segment record of the IDoc contains entire transmitted application data. Thus, SAP standard IDoc monitoring tools are exposing potentially business sensitive data – and for some scenarios, that should be avoided (a good example here are HR scenarios).

 

Let us assume that the requirement is to grant the monitoring team access to all IDoc data except several fields that are contained in specific segments of IDocs of the given message type.

 

AS ABAP authorization concept cannot be utilized to fulfill such a requirement: the SAP standard authorization object for which authorization is checked when accessing IDoc monitoring tools (authorization object S_IDOCMONI) can be used to verify authorization against performed activity (change or display), executed monitoring or test transaction (like WE02, WE05, WE07, WE09, WE10, WE19) and involves check against several fields of the IDoc control record (like direction, message type, partner type, partner number), but doesn’t provide capability of authorization check against IDoc segment level. Thus, it is possible to restrict access to monitoring IDocs of the specific direction and message type, generated for the particular partner, but in case of usage such an approach, access to the whole IDoc will be limited, not to a particular segment or even segment field.

 

For such a requirement, the functionality that can be employed is encryption of contents of IDoc segment field(s) for the specific message type. This is a SAP standard functionality that is available in AS ABAP and that will be described in more details further in this blog.

 

 

By default, encryption of field contents of IDoc segments is disabled – in order to configure this functionality, customizing should be performed using the transaction code WECRYPTDISPLAY. For customizing of this functionality, mandatory fields are: message type, IDoc segment (of the specified message type) and corresponding field (of the specified IDoc segment) for which contents should be hidden:

 

Basic configuration.png

 

Specification of the encryption function (ABAP function module that implements encryption logic) is optional. If it is not specified at customizing step, at runtime the default encryption logic – that is, substitution of all non-space characters with asterisks – will be applied:

 

  • IDoc display: as it can be seen, contents of IDoc segments are shown in plain text:

 

IDoc monitoring - default.png

 

  • IDoc display with enabled encryption: as it can be seen, actual contents of one of the fields of the IDoc segment are hidden:

 

IDoc monitoring 1.png

 

Customizing is specific to the particular field of the specific IDoc segment of the respective message type – thus, if it is necessary to hide contents of more than one field, it is necessary to maintain customizing for each affected field. Maintained and saved settings for encryption of field contents of IDoc segments are persisted in the database table EDCRYPTDISPLAY.

 

Optionally, it is also possible to develop and specify custom function module that would be called to encrypt contents of the field of the IDoc segment. The module’s interface should be:

  • Import parameter I_CCNUM (of type char(255)): when the encryption module is called at runtime, it is passed actual (plain text, before encryption) contents of the field of the IDoc segment via this parameter;
  • Export parameter E_CCNUM_MASKED (of type char(255)): the parameter should be assigned the hidden value (after application of encryption logic) of the field of the IDoc segment.

 

Both parameters can be typed with reference to SAP standard data element FELDINHALT that is commonly used in underlying implementation of the encryption of field contents of IDoc segments.

 

The function module should implement logic that, based on the plain text input of the field value, is responsible for generating the encrypted value.

 

A very simple example of utilization of the custom developed encryption function module is provided below:

 

FM - import.png

FM - export.png

FM - source code.png

Advanced configuration.png

 

As it can be seen, instead of asterisks, the hard-coded text is displayed for the respective field of the IDoc segment:

 

IDoc monitoring 2.png

 

At runtime, when the IDoc monitoring transaction code is executed and IDoc display logic is triggered for the selected IDoc, a list of all fields for which contents are subject for encryption is retrieved (using the function module IDOC_GET_ALL_CRYPT_FIELDS). The next step is application of the encryption logic that is undertaken for each affected field individually by calling function module IDOC_CRYPT_ONE_FIELD. If the custom encryption function module was not specified for the field during customizing, the default encryption logic is applied; otherwise this custom encryption module in invoked by the function module IDOC_CRYPT_ONE_FIELD. Please note that encryption is only affecting the way how IDoc segment data is displayed and corresponding encryption logic is executed “on the fly”, when IDoc display functionality is called – no changes to the original generated and transmitted IDoc or any of its segments take place.

 

 

Please note that the described approach only makes sense when being used in conjunction with proper authorization management. As it has been stated earlier, encryption of field contents of the IDoc segment does not change any data in the IDoc, it only applies adjustment to the output of standard IDoc monitoring transactions. Thus, the actual transmitted content that is hidden in IDoc monitoring tools, can still be accessed in plain text by other means and from other layers – namely:

  • Access from database layer: direct access to tables of IDoc persistence layer and retrieval of IDoc segment data – precisely, querying the table EDID4 for contents of IDoc segment record for the given IDoc;
  • Access from communication layer: e.g. access to contents of Logical Unit of Work (LUW) for tRFC ports, access to ICM traces or trace/interception of HTTP packets for XML HTTP ports, access to files for File and XML File ports, etc.;
  • Access from custom ALE/IDoc monitoring tools: custom developed IDoc monitoring transactions (that can, for example, utilize standard BAPIs like EDI_SEGMENTS_GET_ALL to retrieve IDoc segment record contents) can be used to expose contents that are hidden in standard IDoc monitoring tools;
  • ABAP debugging: execution of standard IDoc monitoring tools in debug mode and retrieval of contents of variables that hold IDoc segment data at runtime can be used to easily bypass described encryption mechanisms.
To report this post you need to login first.

4 Comments

You must be Logged on to comment or reply to a post.

    1. Vadim Klimov Post author

      Hello Michal,

      Yes, I absolutely agree with you that AIF is the more advanced framework – and also in part of monitoring of interfaces. And it surely implements quite a lot of nice and generic features that can be used. But from personal experience and experience of customers, AIF is still not very commonly used, unfortunately.

      Regards,

      Vadim

      (0) 
  1. Alok Sharma

    Vadim,

    Just imagine a scenarion as B2B Integration, where an employee’s payroll data is going out to bank for salary payments. i want to encrpt the Salary component fields data and send it from ERP/S4HANA to SAP PI/PO and then deliver it to bank as a webservice using SOAP Adpater. Now whatever i am encypting from ERP/S4HANA and sending to bank, i need an answer “How bank will decrypt this data sent by SAP systems?”. Please reply at the earliest.

    Regards,
    Alok Sharma

    (0) 
    1. Vadim Klimov Post author

      Hello Alok,

      The requirement you described has no relation to the functionality described in this blog: the mentioned functionality only masks certain fields’ values in standard monitoring tools, it does not apply encryption to actual content transmitted in the generated IDoc. Moreover, given you tend to utilize mediated integration via PI/PO, specifics of which encryption algorithm shall be used when sending data to the banking system is subject for discussion when designing communication flow from PI/PO to the receiver banking system, rather than ERP (as IDoc producer) to PI/PO.

      As for your question, this is truly a question to be addressed to the provider of the banking system or the support team who manages it.

      Regards,

      Vadim

      (0) 

Leave a Reply