Document History

1.    About This Guide

This document describes configuration steps that are required, or are optionally possible, to configure 3Keys Kazakhstan MPT in SAP ATTP system.

2.   Solution overview

SAP ATTP delivers a solution to generate the reporting messages for Russian ISMT system. The 3Keys Kazakhstan MPT Add-On automate the communication and message generation/transfer to Kazakhstan MPT system, visualize the message processing status with monitoring transaction, download and process the inbound documents in ATTP

2.1. Solution scope

In 3Keys Kazakhstan MPT, the following notifications are supported:

The list of supported rule types (notifications) is planned to be enhanced in future 3Keys Kazakhstan MPT releases. Also, you can enhance supported notification by adding custom rule types (See enhancement section).

3. Constraints, Assumptions, Prerequisites and Dependencies

The Kazakhstan reporting part for MPT is configured in SAP ATTP.

4. Setting up the Solution

4.1. Connection to Java part

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

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

The corporate firewall, proxy, gateway, etc. should allow outbound HTTPS connection from ATTP or middleware system to the Connector Java part.

4.1.1. Prerequisites

For setting up an online integration to a Kazakhstan reporting system via MPT connector Java part, do the following:

·       Create an HTTP Destination to MPT connector.

·       Create a System (master data).

·       Maintain settings.

4.1.2. Create an HTTP Destination to MPT connector

To create an HTTP connection to the external server, do the following:

Call transaction SM59

Create a new destination as follows:RFC Destination: Maintain a name for the destination (for example MPT)

• Connection Type: G – HTTP Connection to External Server

• Description: Maintain a description for the destination (for example MPT via 3Keys Kazakhstan connector)

On the tab Technical Settings, maintain the URL in the fields Target Host, Service No. and Path Prefix.

• For example, the URL: https://[URL provided by 3Keys support]/mpt/api results into:

  • Target Host: [URL provided by 3Keys support] (or server name in case on-premise installation)

  • Service No.: 443

  • Path Prefix: /mpt/api

Set the HTTP Proxy Options as required in your organizations network

On tab Logon & Security, do the following:

• Basic Authentication: true

• Input User and password for MPT Connector

• Do Not Send Logon Ticket: true

• SSL: active, Anonymous

On the tab Special Options, do the following:

• HTTP Version: HTTP 1.1

• Compression: Inactive

• Compressed Response: Yes

• Accept Cookies: No

Save the destination.

Click on Connection Test to test the created destination. If the connector and reporting system is reachable and the destination is set up correctly, the test result shows that the HTTP response value is 200 and Text is OK.

Create the second RFC destination identical to created destination without path prefix (to test True API methods). Maintain a name for the destination (for example MPT_API).

4.1.3. Create a system

To create a system, do the following:

1. Call transaction /STTP/COCKPIT

2. Navigate to Master Data > Systems and then Choose Display/Edit.

3. Choose Create. A popup is displayed. 

4. In the popup, define a system name and use following parameters: 

a.      System name (for example MPT)

b.     System Type: D - Domestic

c.      System Group: <EMPTY>

d.     Communication Type: 0 – Not Specified

e.     RFC Destination: Maintain the destination name created in SM59

4.1.4. Technical user and authorization role

One technical user shall be created in ATTP and have authorization to execute web service calls. The authorization to post events is needed if inbound electronic document processing shall generate objects or post events in ATTP.

4.1.5. Maintain service paths

Check and, if needed, maintain the service paths in the view /STTP/V_RSRVPATH via transaction SM30. Industry 20 is default industry for methods, correct product group depends on industry and added before True API request execution

4.2. Event additional properties

The following is a list of expected event properties to compose the notification message. The notification raise error in case the mandatory event properties is not available on the event.

Import from 3rd countries

Import from the EAEU

WriteOff

Act of acceptance and transfer

4.3. Customizing the solution

In general, customizing is performed with following transactions:

• /K3TKZ/PARAM

• /K3TKZ/CUST

• /K3TKZ/CONF

• /K3TKZ/ATTR_MAP

4.3.1. General Customizing

The transaction /K3TKZ/PARAM contains parameters to influence the 3Keys Kazakhstan MPT. The settings will require a customizing transport. The view /K3TKZ/V_PARAM can be used with transaction SM30 for changes without customizing transport

Following the recommended minimum set of parameters

4.3.2. Customizing for Reports

4.3.2.1. Relevant industry

Maintain relevant industry in the transaction /K3TKZ/CUST under “Relevant industry”.

These settings are also used for assignment of customer specific industries to product groups

This mapping will be used to identify correct product group on execution True API request.

Example:

4.3.2.2. Document type description

Maintain document type description in the transaction /K3TKZ/CUST under “Document Type”

4.3.2.3. Mapping attributes

Mapping attributes in the transaction /K3TKZ/CUST under “Mapping attributes” contains attributes for each report used on notification creation. 3Keys Kazakhstan MPT connector already contains predefined mapping attributes for delivered rule types:

4.3.2.4. Product Group

Product group in the transaction /K3TKZ/CUST under “Product group” contains possible values for product groups at MPT system. 3Keys Kazakhstan MPT already contains product groups, maintain additional values in case new product group added:

4.3.2.5. MPT Status send from, MPT Status send to

MPT status customising in the transaction /K3TKZ/CUST under “MPT Status send from” contains possible status values for message sequence check before sending to MPT system. Note “MPT Status change to” contains new status value to be set after receiving successful response for notification. 3Keys Kazakhstan MPT already contains MPT status, maintain values in case other status processing logic is required

4.3.2.6. Reporting message attributes

Participant tax code fields could be filled with value from source or destination fields of the EPCIS event or business transaction in the transaction /K3TKZ/ATTR_MAP.

The following location data source is supported:

BIZTRANS-SHIPFROM - event business transaction document ship from party
BIZTRANS-SHIPTO - event business transaction document ship to
BIZTRANS-SOLDFROM - event business transaction document sold from party
BIZTRANS-SOLDTO - event business transaction document sold to party
EVT-BIZLOC - event business location
EVT-DST-LOC - event destination location
EVT-DST-OWNR - event destination owning party
EVT-READPOINT - event read point
EVT-SRC-LOC - event source location
EVT-SRC-OWNR - event source owning party

The following fields are available for mapping:

CONSIGNEEID - Act of acceptance, Introduce EAEU
IMPORTERCODE - Import from third countries
PARTICIPANTIDENTIFICATIONCODE - Write off
SUPPLIERID - Act of acceptance

4.4. Rule processing

The common rule processing scheme:

The rule type Z3KKZ_MT shall be assigned in the transaction /STTP/CUST_RULES to business steps / location groups related for the MPT Kazakhstan reporting 

The rule type Z3KKZ_MT allows to use additional customizing parameters to determine the rule to be executed, determine the approval parameters, and helps with sequence check. In case event triggered rule contains more than one industry rule type Z3KKZ_MT split objects into several reporting events group by industry.

Maintain the rules in the transaction /K3TKZ/CONF under “Rule Configuration”

Maintain additional parameters in the transaction /K3TKZ/CONF under “Rule Configuration” if required skip specific rules using SAP ATTP rule conditions or class-based rule conditions

SAP ATTP rule condition is based on BADI /STTP/BADI_RULE_CONDITIONS with filter = rule condition (Rule processing will stop check if result is skip rule).

Class-based rule condition is maintained via transaction /K3TKZ/CUST node “Rule condition” and based on class method /K3TKZ/CL_RULES=>GET_RULE_CONDITION_CLASS. Method is used to get class name from table /K3TKZ/C_COND, custom class could be assigned as condition processor. Class method /K3TKZ/IF_3K_RULE_CONDITIONS~EXECUTE is called. (Rule processing will stop check if result is skip rule). 

4.5. Message approval

By default every report is ready for sending. If the explicit waiting of user approval is required activate User Approval check box in the transaction /K3TKZ/CONF under “Configuration ID” 

4.6. Sequence check

The sequence check is active for all outbound notification to MPT system. The sequence check is triggered during the message approval, check sequence function, sending notification to MPT via report /K3TKZ/MPT_DISPATCHER.

Background job needs to be planned for the report /K3TKZ/MPT_DISPATCHER. The sequence check results are stored as application log transaction SLG1, Object /STTP/, Sub object DM, External ID /K3TKZ/MPT_SEND

The logic of the sequence check:

1. Call BADI /K3TKZ/BADI_REP_SEQ_CHECK method BEFORE_CHECK

2. Check objects MPT status (status found). The MPT status tracked for every SGTIN in the table /K3TKZ/OBJ_STA. The SSCC MPT status determined based on the first found SGTIN in the current hierarchy

3. Processing status: there is no report with the same objects in status “Send”

4. Check predecessor: there is no report with the same objects earlier than the current message

5. Call BADI /K3TKZ/BADI_REP_SEQ_CHECK method AFTER_CHECK

The MPT status could be updated with transaction /K3TKZ/MPT_SN_INFO or program /K3TKZ/OMS_REP (if SGTIN was send to OMS with BR_CRYPTO_COMM event).

The sequence check can be skipped/ignored by user in the transaction /K3TKZ/DOC_MONITOR with button Approval

4.7. Configuration ID determination

The Configuration ID represents the user / certificate for login to the MPT system and electronic signature of the message in the connector Java part configuration file. 

Multiple Configuration ID are supported.

Maintain Configuration ID in the transaction /K3TKZ/CONF under “Configuration ID” 

 Maintain Participant Tax code in the transaction /K3TKZ/CONF under “Participant Tax code” 

4.8. Inbound Documents processing

Activate inbound Documents processing in the transaction /K3TKZ/CUST in the transaction /K3TKZ/CUST under “Relevant industry”.

Maintain inbound filter customizing in the transaction /K3TKZ/CUST node “Inbound Filter”

The report /K3TKZ/MPT_DOC_IN shall be planned as a background job to request from MPT and process the documents. The document processing executed with AIF functions and visible in the transaction /AIF/ERR.

The 3Keys Kazakhstan Connector for MPT provides the list of function modules for processing of inbound messages.

Function module /K3TKZ/AIF_DOC_IN_NO_REACTION set document status based on MPT document status.

Assign the processing function module in the transaction /K3TKZ/CONF node “Inbound Document processing”

In common inbound document processing is presented on the following diagram

4.9. Background jobs for report processing

4.9.1. Report sending

The report /K3TKZ/MPT_DISPATCHER (could be planned as background job or run manually via transaction /K3TKZ/DISP) collects created reports with status “Sequence check” and “Ready for sending”, perform sequence check and send report to MPT system and update data:

• Report header / item

• Reporting event 

Program works as single instance for all configurations (based on logical lock).

In case sending failed program updates field “Error text” and leave processing status without change to send report with next run.

The report run results are stored as application log transaction SLG1, Object  /STTP/, Sub object DM, External ID /K3TKZ/MPT_SEND

4.9.2. Response processing

The report /K3TKZ/MPT_RESPONSE (could be planned as background job or run manually via transaction /K3TKZ/MPT_RESPONSE) collects send reports with status “Send”, receives report status from MPT system and updates data:

• Report header / item

Program works as single instance for all configurations (based on logical lock).

First response for report is requested after delay set in the configuration customizing (table /K3TKZ/C_CONF_ID). 

In case no positive response (response http code 200) received for report, program updates:

• field “Error text” with error from JSON

• field “Response code”

• field “Response error counter” - increase value by 1. When response error counter value become more than maximum error counter set in the configuration customizing (table /K3TKZ/C_CONF_ID) report processing status is set to “No response”

• analyze if received HTTP error code is server error (selection screen parameter) during this report run and stop processing if value of screen parameter “Stop after error number” exceeded

The report run results are stored as application log transaction SLG1, Object  /STTP/, Sub object DM, External ID /K3TKZ/MPT_RESPONSE

4.9.3. OMS report processing

The report /K3TKZ/OMS_REP (could be planned as background job or run manually) collects events with processed BR_CRYPTO_COMM reporting events, checks status at MPT system for specific number (subset) of SGTINs and updates data:

• Report monitor header

• Report monitor item

• SGTIN status (APPLIED) for sequence check

The following diagram described program work:

The report run results are stored as application log transaction SLG1, Object  /STTP/, Sub object DM, External ID /K3TKZ/OMS_REP

5. Enhancements of the Solution

The 3Keys Kazakhstan connector MPT solution is designed as to be possibly enhance based on customizing and code enhancements. Code enhancements are realized through BAdI implementations.

5.1.1. Enhancing rule determination

3Keys rule configuration includes a possibility to further refine the selection criteria for a rule to be executed. This can be accomplished by using one of the following options:

• Redefine default rule execution class /K3TKZ/CL_3K_RULE_PROC to custom class using table /K3TKZ/C_RTYPE and implement own logic with ABAP to skip specific rule after rule configuration reading 

Maintain rule type in the transaction /K3TKZ/CUST under “Rule Type”

• Implementing a BADI /STTP/BADI_RULE_CONDITIONS with filter = rule condition 

• Implementing 3Keys rule condition class containing interface  /K3TKZ/IF_3K_RULE_CONDITIONS. Custom logic needs to be created at method /K3TKZ/IF_3K_RULE_CONDITIONS~EXECUTE.

Maintain rule condition in the transaction /K3TKZ/CUST under “Rule Condition”

5.1.2. Change report content

The report JSON generated by ATTP standard may not fit to the business requirements. To change report XML the following options available:

5.1.2.1. Create custom mapping logic

To compose report data, it is possible to use own logic by creating new rule type with own rule type execution class by implementing interface /K3TKZ/IF_3K_RULE_MAPPING (method EXECUTE).

Based on import parameters (event data, industry, rule key) it is necessary to fill output table with AIF structure to transfer data to AIF and create report monitor header and item.

To assign custom execution class use transaction /K3TKZ/CUST, node “Mapping Attributes”, column “Mapper Class”.

5.1.2.2. Change existing mapping logic

To compose report data it is possible to change existing rule type logic by using mapping class redefinition. It is necessary to create own class as child class of /K3TKZ/CL_IMPORT_MAPPER (or copy of this class) and assign this new class to relevant rule type via transaction /K3TKZ/CUST, node “Mapping Attributes”, column “Mapper class”.

5.1.2.3. Change report after mapping

Badi /STTP/BADI_RU_CHANGE_AFTER_MAP shall be implemented for the rule type and own processing logic needs to be implemented.

5.1.3. New custom MPT report type

The new MPT reporting type not existing in the 3Keys Kazakhstan Connector MPT can be created with following steps:

• Create new rule type via transaction /STTP/CUST_RULE_TYPE - Define Rule types

• Create new notification type via transaction /STTP/REP_NOTIF_TYPE - Define Reporting Notification Types

• Create ABAP structures for AIF (use structure /K3TKZ/S_MPT_IMP_AIF as example)

• Create AIF customizing via transaction /AIF/CUST (Namespace /STTC3):

o   Define interface

o   Specify interface engine

o   Define structure mapping

• Create customizing for mapping report content via transaction /K3TKZ/CUST (“Mapping attributes” node)

• Add logic to extract report data implementing BADI /K3TKZ/BADI_REP_PARSE

• Create customizing for new rule via transaction /STTP/CUST_RULES (3Keys General rule)

• Create customizing for new rule via transaction /K3TKZ/CONF (“Rule configuration” node)

• Create logic to parse data by implementing Badi /K3TKZ/BADI_REP_PARSE

5.1.4. New industry

The new industry not supported by SAP ATTP standard can be created with following steps:

1. Create fixed value append for domain /STTP/D_INDUSTRY (for example ZP – Perfume). Skip this step if industry is supported by 3Keys Kazakhstan Connector for MPT.

2. Specify relevant industry for reporting (transaction /K3TKZ/CUST, node “Relevant Industry”) 

3. Add new REST path for created industry (transaction SM30 view /STTP/V_RSRVPATH)

4. Add general customizing parameter RR_RU_NTF_REV for industry using transaction /STTP/CUSTGEN

5.1.5. Create new True API function

The new True API method not existing in the 3Keys Connector MPT can be created with following steps

1. If base class for API processing does not exist create child class of /K3TKZ/CL_TRUE_API_REQ as custom class ZCL_TRUE_API_REQ

2. Create method GET_INSTANCE_ATT as copy of GET_INSTANCE at custom class ZCL_TRUE_API_REQ

3. Create new constant for rest operation (use constant /K3TKZ/CL_REST_CONST=>GCS_REST_OPERATION-NOTIFICATION-MPT-GET_CISES_INFO as example)

4. Add new REST path for created REST operation (transaction SM30 view /STTP/V_RSRVPATH)

5. Create processor class (use class /K3TKZ/CL_TRUE_API_CISES_INFO as example), for example ZCL_TRUE_API_CISES_INFO2

6. Add processor (class ZCL_TRUE_API_CISES_INFO2) instance creation logic into method GET_INSTANCE_ATT (based on rest operation) of base class ZCL_TRUE_API_REQ

7. Implement new created API processing class ZCL_TRUE_API_REQ call into custom code

5.1.6. Enhancement spot /K3TKZ/ES_REP

5.2. Enhancement for navigation to ATTP cockpit

Add general customizing parameter /K3TKZ/COCKPIT_NAVIG (usage scope Customizing) to enable navigation to ATTP Cockpit from transaction /K3TKZ/DOC_MONITOR using transaction /STTP/CUSTGEN