Document History

1.    About This Guide

This document describes mandatory and optional configuration steps to configure 3Keys CRPT Connector for MDLP in SAP ATTP system.

2.   Solution overview

SAP ATTP delivers a solution to generate the reporting messages for the Russian MDLP system. The 3Keys CRPT Connector for MDLP automates the communication and message transfer to the Russian MDLP system, visualizes the message processing status with monitoring transaction, downloads and processes the incoming MDLP messages in SAP ATTP. 

3.    Constraints, Assumptions, Prerequisites and Dependencies

The Russian reporting part for MDLP is configured in SAP ATTP for working with files without SAP ICH.

4.    Setting up the Solution

4.1    Connection to Java part

The connection to the Java part can be set up using RFC or web services technology.

The connector Java part as SaaS solution supports only https communication using web services.

The firewall should be opened in case the connector Java part is not installed on the SAP ATTP server. HTTP or HTTPS port to connect to SAP ATTP can be verified with transaction SMICM. The port for connection using RFC is 33<SYSNR>

 4.1.1    Connection to Java part using RFC

Create RFC destination using transaction SM59.

• Set Connection type: T

• Choose Registered Server Program radio button

• Set Program ID: free name, for example, MDLP_JCO_SERVER. This name should match the value in the configuration file of connector Java part

• Choose Unicode on the Unicode tab

Add the host name to the Gateway ACL file, in case the connector Java part is installed not on the same server as ATTP. Start transaction SMGW choose menu Goto --> Expert Functions --> External Security --> Maintenance of ACL Files

Add new entry into the Reginfo File with the following parameters:

P/D: P, TP: the program name from the RFC destination, Host: hostname or IP address, ACCESS: *, Cancel: internal

4.1.2   Connection to Java part using web services

The configuration of webservices is required if the connector Java part should be connected using http or https connection or if some middleware system is in place between SAP ATTP and connector Java part.

The Root CA certificate of the certificate which is used to secure the connection from SAP ATTP or a middleware system to the connector Java part, should be added to the SSL client (Anonymous)  in the transaction STRUST if https connection is used.

Start transaction SOAMANAGER, navigate to the Service Administration à Web Service Configuration

Create logical port for consumer proxies using Manual Configuration option. Logical port name is free to choose but must be the same for all consumer proxies.

The values for user, password, URL port and Transport Binding Type (SOAP 1.1 or SOAP 1.2, the default value is SOAP 1.1) shall match the values in the configuration file of the connector Java part.

Create binding for the Service definitions

Choose the radio button SSL if https connection is used, otherwise None for http. Activate User ID/Password check box for the Transport Channel Authentication.

4.1.3    Technical user and authorization role

One technical user shall be created in SAP ATTP with authorization to login and execute RFC calls (name space /K3T/*), if connector Java part used RFC, or execute web service calls (authorization object S_SERVICE). The authorization to post events is needed if inbound MDLP message processing shall generate objects or post events in SAP ATTP.

4.2    Parameters

The transaction /K3T/RU_PARAM contains parameters to govern the 3Keys CRPT connector MDLP. The settings will require a customizing transport. The view /K3T/RU_PARAM_V can be used with transaction SM30 for changes without customizing transport.

Following the recommended minimum set of parameters

4.3    Rule processing

The rule type Z3K_RR_RU shall be assigned in the transaction /STTP/CUST_RULES to business steps / location groups related for the MDLP Russian reporting

The rule type Z3K_RR_RU allows to use additional customizing parameters to determine the rule to be executed, determine the approval parameters, and helps with sequence check.

Maintain the rules in the transaction /K3T/RU_CONF under “Rule Configuration”

Maintain additional parameters in the transaction /K3T/RU_CONF under “Rule Configuration” if required to specified approving behavior or Configuration ID

 4.4     Configuration ID determination

The Configuration ID represents the user / certificate for login to the MDLP system and electronic signature of the message in the connector Java part configuration file. Also, Configuration ID used in the authorization checks in the transaction /K3T/RU_MONITOR. The message cannot be sent without determined Configuration ID and must be entered manually in the transaction /K3T/RU_MONITOR.

Maintain Configuration ID in the transaction /K3T/RU_CONF under “Configuration ID”

 Assign the MDLP long (36-digit participant GUID ) and short(14-digit domestic location ID) Subject ID in the transaction /K3T/RU_CONF under “MDLP Subject ID”, if Configuration ID shall be determined based on the Subject ID

 Assign GLN in the transaction /K3T/RU_CONF under “GLN assignment”, if Configuration ID shall be determined based on GLN in the event. Without posting event the Configuration ID cannot be determined

 4.5     Inbound message processing

Maintain Configuration ID for inbound MDLP messages download in the transaction /K3T/RU_CONF under “Inbound message filter”

 Maintain Configuration ID for outbound MDLP messages download in the transaction /K3T/RU_CONF under “Outbound message filter”. Currently message type 10311, 10319 will be downloaded

 The MDLP inbound messages will be downloaded by the connector Java part and transferred to SAP ATTP.

The report /K3T/RU_MDLP_IN shall be planned as a background job to process the inbound messages. The message processing executed with AIF functions and visible in the transaction /AIF/ERR.

Assign the processing function module in the transaction /K3T/RU_CONF under “Inbound message processing”.

 The 3Keys CRPT connector for MDLP provides the list of function modules for processing of inbound messages.

 Following the recommended minimum set of function modules assignment

 4.5.1     Russia inbound SCN attribute mapping transaction /K3T/RU_SCN_MAP

Transaction /K3T/RU_SCN_MAP allows configure source/destination data for shipping event posted by function module /K3T/RU_AIF_IN_SCN based on customizing table.

Location data could be configured as:

• Fixed value (constant value in customizing table)

• Message field (get specified field from inbound message and find business partner GLN/location GLN by registration number)

To maintain source/destination via transaction /K3T/RU_SCN_MAP:

Select node “Inbound message processing”

Select line with function module /K3T/RU_AIF_IN_SCN and relevant MDLP document type, subject ID, sender ID

Select node “SCN source/dest attribute mapping”

Insert source/destination entries for posting event

1.  Select node “SCN events” to deactivate EPCIS events to be created with function module /K3T/RU_AIF_IN_SCN. By default commissioning, aggregation, receiving, shipping will be posted. Deactivate checkbox for specific event if posting is not needed.

2. Select node “Message field” to set possible values for reporting message field selection.

 4.6     Message approval

Every message must be approved for sending. The approval can be done automatically based on configuration or manually in the transaction /K3T/RU_MONITOR.

The approval user, group, and explicit waiting of user approval determined with following logic:

1. Get values from Rule parameters (transaction /K3T/RU_CONF under “Rule Configuration”)

2. Get values from GLN parameters (transaction /K3T/RU_CONF under “GLN assignment”)

3. Get values from Subject ID parameters (transaction /K3T/RU_CONF under “MDLP Subject ID”)

4. Get values from Configuration ID parameters (transaction /K3T/RU_CONF under “Configuration ID”)

Maintain the Approval Group and assign User to the Approval Group in the transaction /K3T/RU_CONF under “Approval group”, if approval shall be controlled by Approval Group assignment.

4.7     Sequence check

The sequence check could be activated with parameter /K3T/CHECK_MDLP_SEQUENCE = X in the transaction /K3T/RU_PARAM. The manual approval will be required if the sequence check is not activated from the beginning, because the serial number MDLP status will not be updated with the incoming MDLP response before activation. The sequence check is triggered during the message approval, receiving MDLP response and as background job to be planned for the report /K3T/RU_MDLP_DISPATCHER with variant including disabled “Test run” field. The sequence check results stored as application log transaction SLG1, Object /STTP/, Sub object REP, External ID /K3T/MDLP_SEQUENCE

The logic of the sequence check:

1. No sequence check for messages 250-252, 10311, 10319

2. Check objects MDLP status, maintained in the transaction /K3T/RU_CONF under “Sequence Message sending”, allow for the MDLP document type. Aggregation messages 911-915 excluded from this check. The MDLP status tracked for every SGTIN in the table /K3T/RU_MDLP_STA. The SSCC MDLP status determined based on the first found SGTIN in the current hierarchy

3. Check the predecessor message exist for the same objects (messages currently in processing or confirmed with error from MDLP, messages with earlier operation data)

4. The message 915 checked to send parts in correct order. The parts of SGTIN-SSCC shall be send first and confirmed by MDLP before sending another SSCC-SSCC parts

The MDLP status will be updated with confirmation message from MDLP based on the values in the transaction /K3T/RU_CONF under “Sequence Status changing”

The sequence check can be skipped/ignored by user in the transaction /K3T/RU_MONITOR with button Approval.

MDLP message response triggering the Dispatcher as background job based on event.

Create background job event with transaction SM62

Event: /K3T/TRIGGER_MDLP_SEND

Description: Trigger job for sending message to MDLP system

Include the event definition into workbench transport to be able to import in the next environment.

Create variant PROD_RUN for report /K3T/RU_MDLP_DISPATCHER and disable the Test check box.

Create background job with transaction SM36 using Job wizard

Job name: for example, /K3T/TRIGGER_MDLP_SEND

ABAP program step: active

ABAP program name: /K3T/RU_MDLP_DISPATCHER

Variant: PROD_RUN

After event: active

Select event /K3T/TRIGGER_MDLP_SEND and Periodical check box

4.8     Background jobs for queue monitoring

The message sending to MDLP is synchronized using queues.

The report RSQOWKEX shall be planned as a background job with variant includes following field values: Queue Name: *, Queue Destination: *, Queues running longer than: blank, No Running Queues check box active, No Retry Queues check box inactive

Register destination in the transaction SMQS. The Destination shall be the same as the Host ID, Max Conn: 1000, Max Runtime: 600

4.9    Data deletion

The report /K3T/RU_MDLP_CLEANUP shall be planned as a background job to delete temporarily stored data with variant fields: “Delete msg objects/XML” check box active, “Test Mode” check box inactive, “Delete data older as days” for example 30.

The report /K3T/RU_MDLP_CLEANUP can be also planned to delete Logistic monitor data and MDLP monitor data with retention period align with company retention policy.

4.10     OMS dynamic token

The OMS dynamic token refresh can be planned as background job with report /K3T/RU_OMS_TOKEN. The OMS Connection ID assignment to the system and MDLP Configuration ID shall be maintained in the transaction /K3T/RU_OMS_C.

4.11     Russia MDLP Analytics

MDLP analytics reports functionality is available, including ability to request following reports: Remaining medicines, Medicine disposal, SSCC Hierarchy, Pricing report, General report Pricing report, General report on movement, General report on remaining item, General report on disposal.

To receive analytic reporting data from MDLP system the following steps are required:

• Schedule report run - create analytic reporting request and task (according to MDLP API requirements) using transactions /K3T/RU_MAR_SCD_* (For example, /K3T/RU_MAR_SCD_MD - Task scheduler Medicine disposal) or /K3T/RU_MAR_SCD_GEN_* (General reports, for example, /K3T/RU_MAR_SCD_GEN_MD - Task scheduler Medicine disposal)

• Run task processor (program /K3T/RU_MAR_TASK_PROC for tasks or /K3T/RU_MAR_REP_PROC for general reports) to create tasks at MDLP, receive task results and save as ZIP file into database table

• Run task execution (program /K3T/RU_MAR_TASK_EXEC) to extract data from ZIP file and save data to database or send data to external database

• Monitor task execution (transaction /K3T/RU_MAR_MONITOR)

4.11.1     Russia MDLP Analytics: Configuration transaction /K3T/RU_MAR_CONF

Transaction /K3T/RU_MAR_CONF allows configure processing after data retrieval from MDLP system specific for each report type based on customizing table.

Assign the processing function module for specific report under “Analytic Report”.

The 3Keys CRPT connector for MDLP provides the list of function modules for processing of analytic reporting data.

Maintain exclude fields under “Response Exclude fields” to exclude unnecessary data from report.

4.11.2     Report /K3T/RU_MAR_TASK_PROC - Russia MDLP Analytics: Task processor

The report /K3T/RU_MAR_TASK_PROC shall be executed periodically as background job for sending requests to the MDLP and downloading results. The multiple background jobs can be planned for each MDLP Configuration ID to execute in parallel. The selection screen fields:

• MDLP Configuration ID

• Wait Time First Response: Default wait time in seconds between request and results download

• Max Wait Time After Crt: maximum processing time after request was registered by MDLP system and response is expected. If no response is received task status will be set to error

• Between Status Check (sec): wait time in seconds between task status check

• Create new Log after seconds: create new SLG1 log after specified interval from report run to monitor program execution

• Maximum runtime program (min): maximum program processing time before stop with error

• Max Server Errors: maximum server errors series before stop with error

• Queue processing method. Available values:

  • 1 - “FIFO” (default value) means task will be processed in order task have been created

  • 2 - “Create if slot is available” means program will create new task after each successful task result processing when free slot is available at MDLP side (to minimize wait time between task creation)

• Retry after FAILED: repeat processing after first FAILED response from MDLP system

• Delete unknown MDLP tasks: delete tasks from MDLP system queue (if task from MDLP queue with MDLP id and status “Send to MDLP” is not found):

  • before first task processing to delete existing entries in queue

  • after all task processing to delete entries after MDLP side server errors

  • on receiving server error series

Block “Available tasks operation retry option“

• Retry after failure times: how much tries needs to be done after each failure

• Delay after failure (sec): the initial delay in seconds after first negative response. Value must be greater than 0

• Backoff: the factor by which the delay should be increased after each failure. Value must be greater than 1

Block “MDLP queue operation retry option“

• Retry after failure times: how much tries needs to be done after each failure

• Delay after failure (sec): the initial delay in seconds after first negative response. Value must be greater than 0

• Backoff: the factor by which the delay should be increased after each failure. Value must be greater than 1

Block “Delete operation retry option“

• Retry after failure times: how much tries needs to be done after each failure

• Delay after failure (sec): the initial delay in seconds after first negative response. Value must be greater than 0

• Backoff: the factor by which the delay should be increased after each failure. Value must be greater than 1

Block “Result operation retry option“

• Retry after failure times: how much tries needs to be done after each failure

• Delay after failure (sec): the initial delay in seconds after first negative response. Value must be greater than 0

• Backoff: the factor by which the delay should be increased after each failure. Value must be greater than 1

Block “Create operation retry option“

• Retry after failure times: how much tries needs to be done after each failure

• Delay after failure (sec): the initial delay in seconds after first negative response. Value must be greater than 0

• Backoff: the factor by which the delay should be increased after each failure. Value must be greater than 1

Block “Task response wait options”

• Retry after max wait times: Each task created at MDLP system existing without final status (COMPLETED or ERROR) is checked for processing time (task creation time at MDLP + “Max wait time after creation (sec)” is less than time now). In case task processing time is more than “Max wait time after creation (sec)” seconds task processing is stopped by program and task is deleted from MDLP with error “Maximum response time reached. Setting error status”. For each task now new internal max wait time counter implemented to create new task at MDLP instead of stop task processing if counter value is less than “Retry after max wait times”.

Report read tasks ID and process tasks according to MDLP API requirements. In correct scenario task status is changed:

• status 00-new to status 10-Sent to MDLP: task created at MDLP successfully

• status 10-Sent to MDLP to status 20-Ready (results downloaded from MDLP): task data retrieval is completed and task deleted from MDLP

The task processing results stored as application log transaction SLG1, Object /STTP/, Sub object ANY, External ID /K3T/MR_TASK_PROCESSOR.

4.11.3     Report /K3T/RU_MAR_TASK_EXEC - Russia MDLP Analytics: Task execution

The report /K3T/RU_MAR_TASK_EXEC shall be executed periodically as background job for processing downloaded results. The function module shall be assigned in the transaction /K3T/RU_MAR_CONF.

The selection screen fields:

• MDLP Configuration ID

• MR Task Internal Identifier: run report for specified task ID

The task execution results stored as application log transaction SLG1, Object /STTP/, Sub object ANY, External ID /K3T/MR_TASK_EXEC.

4.11.4     Report /K3T/RU_MAR_REP_PROC - Russia MDLP Analytics: Task processor (General Report)

The report /K3T/RU_MAR_REP_PROC shall be executed periodically as background job for sending requests to the MDLP and downloading results. The multiple background jobs can be planned for each MDLP Configuration ID to execute in parallel. The selection screen fields:

• MDLP Configuration ID

• Wait Time First Response: Default wait time in seconds between request and results download

• Max Wait Time After Crt: maximum processing time after request was registered by MDLP system and response is expected. If no response is received task status will be set to error

• Between Status Check (sec): wait time in seconds between task status check

• Create new Log after seconds: create new SLG1 log after specified interval from report run to monitor program execution

• Maximum runtime program (min): maximum program processing time before stop with error

• Max Server Errors: maximum server errors series before stop with error

Block “Available tasks operation retry option“

• Retry after failure times: not used, obsolete

• Delay after failure (sec): not used, obsolete

• Backoff: not used, obsolete

Block “MDLP queue operation retry option“

• Retry after failure times: how much tries needs to be done after each failure

• Delay after failure (sec): the initial delay in seconds after first negative response. Value must be greater than 0

• Backoff: the factor by which the delay should be increased after each failure. Value must be greater than 1

Block “Delete operation retry option“

• Retry after failure times: how much tries needs to be done after each failure

• Delay after failure (sec): the initial delay in seconds after first negative response. Value must be greater than 0

• Backoff: the factor by which the delay should be increased after each failure. Value must be greater than 1

Block “Result operation retry option“

• Retry after failure times: how much tries needs to be done after each failure

• Delay after failure (sec): the initial delay in seconds after first negative response. Value must be greater than 0

• Backoff: the factor by which the delay should be increased after each failure. Value must be greater than 1

Block “Create operation retry option“

• Retry after failure times: how much tries needs to be done after each failure

• Delay after failure (sec): the initial delay in seconds after first negative response. Value must be greater than 0

• Backoff: the factor by which the delay should be increased after each failure. Value must be greater than 1

Report read tasks ID and process tasks according to MDLP API requirements. In correct scenario task status is changed:

• status 00-new to status 10-Sent to MDLP: task created at MDLP successfully

• status 10-Sent to MDLP to status 20-Ready (results downloaded from MDLP): task data retrieval is completed and task result deleted from MDLP

The task processing results stored as application log transaction SLG1, Object /STTP/, Sub object ANY, External ID /K3T/MR_TASK_PROCESSOR.

4.12     Manual signature

Manual signature functionality is available for sending outbound reports and receiving inbound reports via SAP GUI and Crypto Pro SSF software installed on the user local PC. Combined scenario with non-resident, resident MDLP cabinet with manual signature and without manual signature are supported.

4.12.1     Prerequisites

Prerequisite of manual signature are the following:

• Crypto Pro SSF software installed on the user local PC

• Crypto Pro setup refer to the configuration guide

• In case Java part use HTTPs the binding shall be created for new Web services

4.12.2     ATTP customizing

Maintain certificate ID assignment to the user and configuration ID via transaction /K3T/RU_SSF_C - “Russia MDLP Certificate assignment”.

Activate checkbox “Signature required” for Configuration ID via transaction /K3T/RU_CONF node Configuration ID.

Activate field “User approval” to stop message in status ‘01’ and wait for the user Approval in the transaction /K3T/RU_MONITOR.

4.12.3     Token update

In case of manual signature scenario token is stored at MDLP Connector Java part and updated from transaction /K3T/RU_MONITOR manually by user. MDLP system interaction works automatically if connector has active token and wait if token is expired until token renewed by the user.

To update token please execute the following steps:

• Run transaction /K3T/RU_MONITOR

• Execute report selection using manual signature configuration as a filter

• Select report line with using manual signature configuration

• Press menu button “Manual Signature” and choose option “Update Token”. System checks if token is still active and provide Popup window to confirm token need to be updated

• Popup window for Digital signature appears

• Enter your certificate password and press “Sign”

• Security settings window appears to confirm access to local PC

• Message token updated successfully appears

4.12.4     Report sending

In case of manual signature scenario report is always send to MDLP system manually and signing by the user before sending to MDLP Connector.

To update token please execute the following steps:

• Run transaction /K3T/RU_MONITOR

• Execute report selection using manual signature configuration as a filter

• Select report line with using manual signature configuration

• Press “Approval button”

• System checks if token is still active and provide Popup window to sign data and receive new token if token needs to be updated:

  • Popup window for Digital signature appears

  • Enter your certificate password and press “Sign”

  • Security settings window appears to confirm access to local PC

• System execute signature for report before sending to Connector:

  • Popup window for Digital signature appears

  • Enter your certificate password and press “Sign”

  • Security settings window appears to confirm access to local PC

• Report is sending to Connector and report status is changed to 20-Send

4.12.5     MDLP interaction

In case of manual signature scenario it is important to have active token before MDLP calls.

The check of the valid MDLP token added into transaction /K3T/RU_MONITOR to the MDLP Message menu buttons like “Display message XML” “Display Response XML” etc.

The check of the valid MDLP token added to the following transactions:

• /K3T/RU_MDLP_SN_INFO Russia MLDP serial number info

The following corrections implemented into program /K3T/RU_MDLP_DISPATCHER:

• report manual signature filter - reports with manual signature configurations will not be send to MDLP system by program (only using approval button via transaction /K3T/RU_MONITOR)

The following corrections implemented into program /K3T/RU_MDLP_IN (Inbound message processing):

• report manual signature filter - reports with manual signature configurations will be processed only in case active token exists for configuration

• API methods will be used to receive information for reports with manual signature from MDLP independently of system customizing (This correction works at inbound processing modules, for example, Function module /K3T/RU_AIF_IN_SCN will receive hierarchy information using API method not by using 210 / 220 XML message)

The following corrections implemented into transaction /K3T/RU_OMS_TOKEN - Russia OMS token:

• report manual signature filter - OMS token for manual signature configurations will not be updated by program if program is executed on background mode (only dialog mode)

• manual signature - If OMS token for manual signature configuration need to be updated additional popup window appears to execute manual signature to sign authorization data via SAP GUI and Crypto Pro SSF integration. After signature data is send to MDLP Connector Java part and token is updated at ATTP system

5.     Enhancements of the Solution

The 3Keys CRPT connector MDLP is designed to be able to enhance based on customizing and code enhancements. Code enhancements are realized through Badi implementations.

 5.1     Rule execution class

The standard rule execution class /K3T/CL_RR_RU_RULE for the rule type Z3K_RR_RU can be replaced with customer class in transaction /K3T/RU_RULE_PRM.

3Keys CRPT connector MDLP delivered with additional rule types for message types.

The Rule Type assignment to Notification Type and AIF parameters is stored in the transaction /K3T/RU_CRULE 

5.2     Changing message content

The message XML generated by SAP ATTP standard may not fit to the business requirements or some of the mandatory fields in the message shall be updated by the user in the transaction /K3T/RU_MONITOR function “Maintain missing data” before the XML generation.

The Badi /STTP/BADI_RU_CHANGE_AFTER_MAP shall be implemented for the rule type and one of the methods from the class /K3T/CL_RU_BADI_UTILS shall be include in the processing logic.  Following example for Rule type

5.2.1     Russia reporting attributes mapping transaction /K3T/RU_ATTR_MAP

The transaction /K3T/RU_ATTR_MAP contains fields and customizing for the message attributes mapping to replace the message XML fields determined by SAP ATTP standard

To maintain attribute mapping via transaction /K3T/RU_ATTR_MAP:

Select node “Attributes mapping”

Insert new attribute setting

 Select node “Source for GLN” – possible values for GLN determination are predefined

 Select node “Message field” to set possible values for reporting message field selection

Select node “Ignore SAP message” to set SAP standard message to be ignored on attribute mapper processing. SAP standard logic executed before attribute mapper and in case there is no value for mandatory field error added to log and mapping error occurs on reporting message generation. Option “Ignore SAP message” allows to delete specified error in customizing.

5.3     Enhancement spot /K3T/ES_REP_RU

5.4     Enhancement for navigation to ATTP cockpit

The class /STTP/CL_UI_COCKPIT method HANDLE_USER_COMMAND shall be extended at the end of ABAP code to be able to navigate from transaction /K3T/RU_MONITOR to ATTP cockpit to display event, business transaction, reporting event. Following the example of the ABAP code

  IF ( iv_fcode EQ /k3t/cl_rr_ru_const=>gc_cockpit_node-serialized_trade_items ).
    me->trigger_node( iv_node_key = /k3t/cl_rr_ru_const=>gc_cockpit_node-serialized_trade_items ).
  ELSEIF ( iv_fcode EQ /k3t/cl_rr_ru_const=>gc_cockpit_node-business_transactions ).
    me->trigger_node( iv_node_key = /k3t/cl_rr_ru_const=>gc_cockpit_node-business_transactions ).
  ELSEIF ( iv_fcode EQ /k3t/cl_rr_ru_const=>gc_cockpit_node-events ).
    me->trigger_node( iv_node_key = /k3t/cl_rr_ru_const=>gc_cockpit_node-events ).
  ELSEIF ( iv_fcode EQ /k3t/cl_rr_ru_const=>gc_cockpit_node-reporting_events ).
    me->trigger_node( iv_node_key = /k3t/cl_rr_ru_const=>gc_cockpit_node-reporting_events ).
  ENDIF.

Activate parameter /K3T/MON_NAVIG_ACTIVE = X in the transaction /K3T/RU_PARAM