The picture above depicts the overall building blocks of Integration Advisor. This blog post mainly relates to the Type Systems (B2B Library) area.

Tradacoms Library in Integration Advisor

GS1 TRADACOMS was the core UK message standard from the early days of EDI in the UK retail industry. It was widely used by retailers and wholesalers for EDI order and invoice processes between buyers and their mainly UK-based suppliers.

The Tradacoms standard provided so called Transmission Files which are a predefined combination of single message types.

In the above screenshot, for example, you can see the Invoice Transmission File (INVFIL_FILE) which is a combination of single message types INVFIL, INVOIC, VATTLR, INVTLR and RSGRSG.

Versioning in the Tradacoms Library

Tradacoms versioning strategy is different from Edifact release strategy.

Edifact publishes so called release versions (for example D.01B or D.16A) which contain all artefacts (messages, segments, data elements and codelists) at a given time. Each release forms a complete content package and single artefacts (like messages) might or might not have changed compared to the release before.

The Tradacoms Message Standard (similar to the Odette Message Standard), however, versioned all their messages separately. For example, “INVFIL:6” in above screenshot represents the message INVFIL in version 6.

Due to this versioning strategy and the fact that no updates to the Tradacoms messages are expected, you will find all definitions together in one version called “All”.

In Integration Advisor, the Transmission Files are available under the Messages tab. The single message types (such as INVFIL, INVOIC) are not offered as they can’t be used separately by themselves.

The Tradacoms delivery contains 25 different transmission files. For most of them only the newest version is provided while for six of them two versions are available. For example, ORDHDR_FILE:9 represents Version 9 of the Order file and INVFIL_FILE:8 represents Version 8 of the Invoice file.

The following conventions are used to define Identifier and Version number of the Transmission Files:

• The Header Message of the Transmission File determines the Identifier.
  • This convention was derived from the Tradacoms Codelist 16 and the use of these code values in envelope field STX > APRF.
• Moreover, _FILE was added to the Identifier to distinguish between the overall Transmission File and its Header Message.
• The Version of a Transmission File is consistently derived from the version of the Main Message.

For example: The older transmission file for Invoice (Invoice File) consists of five single messages: header message INVFIL (Version 6), main message INVOIC (Version 8), VAT trailer message VATTLR (Version 6), trailer message INVTLR (Version 5) and reconciliation message RSGRSG (Version 2). Applying the rules mentioned above, this Invoice File will be INVFIL_FILE:8 – Invoice File (Version 8).

Please note that the identifiers and versions of the Transmission Files are not defined by Tradacoms standard (by GS1 organization) itself. Different users and data providers have applied different conventions due to which sometimes transmission files are named after the main message and sometimes versions of the transmission files are derived from the version of their respective header message. For example, the older Invoice File (see above) might also be called INVOIC (Version 8) or INVFIL (Version 6).

Tradacoms Usage in Cloud Integration

Cloud Integration has been extended as well to support the processing of Tradacoms Messages.

All relevant EDI Flow Steps (like EDI Splitter or EDI-To-XML-Converter) now offer a third configuration option TRADACOMS besides the earlier options X12 and EDIFACT.

In these EDI Flow Steps (within your Integration Flow) you need to refer to the XSD for your Tradacoms message. These XSDs will be created by Integration Advisor as part of the Runtime Export. The file names of these XSDs follow a standard naming convention: For example, above Invoice transmission file is exported as TRADACOMS_INVFIL_FILE_8.xsd.

Please note that the EDI Splitter works slightly different considering the semantics of the Tradacoms transmission files: If a transmission contains 5 main messages (like INVOIC), then the EDI Splitter will produce 5 separate Cloud Integration messages (one for each of these 5 main messages). Each of these 5 Cloud Integration messages will not only contain the respective main message, but also the header and trailer messages (INVFIL, INVTLR etc.) which are duplicated into all 5 split messages. This way, further processing like mapping is simplified.

The post Integration Advisor – Tradacoms Message Standard appeared first on ERP Q&A.

1. Use Transaction RZ11 to set the value of the profile parameter icm/HTTPS/client_sni_enabled to true.

2. Use Transaction SALE to Create Logical System and then assign the Logical System to the client.

Create Logical System

3. Assign the logical System to Client

4. In the Cloud Platform Trial Account – Go the integration Suite and Choose Operations View Choose leystore and create a new Key pair for CPI

5. Enter the required value and choose Create and down the Certificate file

6. Back in ECC NPL ABAP System – Start the transaction STRUST and choose SSL Client Standard and import the file that was downloaded in the previous step – Choose Add Certificates and Save these changes

7. Create and RFC Destination type G in transaction SM59

the path prefix is the IFLOW we will create in subsequent Steps with the the user name and password is the clientid and client secret that you can get the CPI Service instance config file.. For SSL Certificates choose the Default SSL that you had imported the client Corticates in STRUST.

8. Check the RFC Connection you can 500 or Not Found is the IFLOW is not yet created.

9. As we plan to send IDOC we need to activate the Service /sap/bc/idoc_xml show below

10) To Select the IDOC message type and Basic type go transaction and note FLIGHTBOOKING_CREATEFROMDAT and Basic type FLIGHTBOOKING_CREATEFROMDAT01

10. Go to transaction WE21 and Create XML-HTTP port that is used to send IDOC XML

11. Create a Partner Profile for NPLCPI001 for partner type LS using the transaction WE20

12. Configure the output bound Parameters in the same transaction WE20

13. Now We Create the IFLOW in cloud Platform Integration Suite as shown below

14. Choose the IDOC and enter the parameters as follows. Please note that /cxf is omitted from the address field as this automatically added by CPI on deployment

15. In the Content Modifier we will add three header variables that we will send in the email body. The content Modifier is as shown below

16. To configure email we need to create email credentials in the security material in the operations view.

17. Configure the Email Adapter properties as show below

18. Save and Deploy the Integration and make sure that it has started by checking in the operations view

19. To Test this we will Trigger IDOC from WE19 and choose the the option via message type and enter FLIGHTBOOKING_CREATEFROMDAT

20. Click the Root EDIC and enter the following information

21. Click the node E1BPSBONEW and enter some valid information for Flight Booking

22. We have all the information for the IDOC – Click Standard outbound processing on the top right and make sure any errors are resolved. You can also check in Tcode WE02 that an IDOC with Status 3 has been created due the previous steps.

23. Now we go the SAP Cloud Platform integration and choose operations View – Select the Deployment and choose View Message Monitoring and make that success message is displayed for this or look at any error message by change the info to trace and resend the idoc to resolve any error

24. Check you email account to verify the email has been received as configured in the email adapter settings the IDOC content

The post Send IDOC From ABAP Trail Version NPL to Cloud Platform Integration appeared first on ERP Q&A.