Chem XML Message eStandards and CIDX Scenario - Part I

By Suraj Kumar Pabbathi, PI Competency Lead, YASH Technologies

In this tutorial, we would discuss about CIDX Message eStandards starting from expanding CIDX. CIDX
stands for Chemical Industry Data Exchange.
With the advent of eBusiness, companies in chemical industry adopted certain common communication
principles to reduce the overall cost of XML-Based integration projects to realize business transactions with
partners. These common principles are based on eStandards known as Chem eStandards which are used
by chemical industries for exchanging data Business-to-Business (B2B) and Business-to-Marketplace.
To learn more of Chem-eStandards, download the document fromhttp://xml.coverpages.org/Chem-
eStandardsV20.pdf and go through it.
To facilitate the use of automated data exchange between chemical companies, CIDX an organization has
transformed its organization to operate as standards organization. It will support and maintain the Chem
eStandards. Its official website is www.cidx.org.
For making the messages interoperable across the chemical industries based on XML standards, chem
eStandards leverage the transport, envelope and security aspects of RNIF version 1.1 as described below
diagrammatically:

Find below the explanation of every part of the Chem eStandard Message.
Preamble: It handles information global to document (version, datestamp)

Sample Preamble of the message is as follows:

Service Header: It contains the information about transaction routing and processing information for a given
transaction. The service header contains three separate data objects:
1. Process identity: It describes the process to be carried out by the transaction encapsulated in service
content.


2. Service Route: It describes to and from information.


3. Transaction control: It provides the information how the transaction encapsulated in the service content
is to be processed.



Service Content: This contains the actual message that is considered to be an action message which needs
to be transported to partner.
Chem eStandards is developed with number of conventions for content and structure of the data
models/messages as described below under sections, Message Definition, Message Responses, Message
structure, Message elements.
Message Definition: They are defined with two facets of guiding principles.
1. Individual messages are intended to support only one business function. Eg: OrderCreate is different
OrderChange
2. Individual messages supporting a single business function can modify the nature of transaction being
performed based on data values.
For Eg: OrderCreate message support Standard Order, RushOrder etc..
Message Responses: There are two types of Responses. Technical and Transaction Responses.
1. Technical responses are returned to source system from destination upon deliver of messages from
source to destination. Again there are two types.
a. Positive:
i. ReceiptAcknowledgement is positive Chem eStandard Signal message. When
received, it means that the message is received by partner and the message is valid
chem eStandard Action message.
b. Negative:
i. ReceiveAcknowledgementException: Received by source to state that the partner
has received a message which is invalid in terms of schema validation against DTD
ii. General Exception: Received by source system when processing of action message
by partner runs into error.
2. Transaction Response: They are reply or response to requested Action Message. For eg: Purchase
Order Response is sent by partner as a response to the action message received like Purchase Order.
They are unique and it is not necessary that every transaction has transaction
response.
Note: Action message is the actual message that is sent to partner. Eg: Invoice
Signal message is the response message that is received by source system in response to the action
message received by partner.
Message Structure: It is XML document conforming to corresponding DTD (Data type definition). Every
message will start with a root element addressing the message itself and has child elements as Header and
Body.

Message Elements: An XML specification describes structure data as explained above. XML document
elements may either contain other data elements or data (or both). These message elements may contain
attributes that describe the data within the message element.
On the whole transactions can be exchanged between business partners with a sample explained
diagrammatically below:




























Chem XML Message eStandards and CIDX Scenario - Part II
By Suraj Kumar Pabbathi, PI Competency Lead, YASH Technologies
In part I, we have discussed about CIDX Message eStandards. Now let us discuss how to configure and
design the objects to support the communication based on CIDX standards in XI.
This is achieved by designing the Message types in Integration Repository and configuring collaboration
profiles using CIDX adapter in Integration Repository.
CIDX Adapter: CIDX Adapter supports the chem eStandards described in PartI and facilitates to send the
messages between Integration Server and Partner System by transforming the message format in XML to
message format compliant to chem eStandard Business transaction (chem XML Message) and vice-versa.
It supports Single-Action Asynchronous business transaction, in the sense, at a time it can send only single
action message (for e.g.: Invoice) to partner system in asynchronous mode.
There is variety of chem eStandard business transactions described in the chem eStandard
document http://xml.coverpages.org/Chem-eStandardsV20.pdf that can be exchanged with partner
participating in different roles such as buyer, seller and so on.
For eg: some of the transactions supporting Logistics execution are listed below; where in third column
indicates Global Process Indicator code of chem XML Transactions.








Fig: Sample Transaction Code List
The messages when sent by Integration Engine to Adapter Engine, in Adapter Engine, the messages are
enveloped as RNIF Action and Signal messages as specified in RNIF 1.1 specification.
Find below the step by step procedure to design and configure the scenario to send a sample (Invoice)
message to Partner system.
Design time activities in Integration Repository:
XI message based on chem. eStandards, must be compliant with message interface content in repository.
This means that the DTDs/Schemas need to be downloaded from www.cidx.org and uploaded into
Integration Repository through External Definitions as illustrated in the screenshot below:

Observe that Software component CIDX has Software component version 1.0, which in turn has different
namespaces created under them.
These namespaces and Schemas should be supporting chem. eStandards, as CIDX Adapter
determines/constructs the namespace and interface name of an incoming CIDX Action Message as follows:
<Version> := /ServiceHeader/ProcessControl/ProcessIdentity/VersionIdentifier
Version: Specify the selected version of the message chosen from the schemas available
from www.cidx.org
<Requesting Message> := /ServiceHeader//ActionControl/ActionIdentity/GlobalBusinessActionCode
Requesting Message: A big list of messages are provided which would suit the business transactions
performed between chemical companies. They support many scenarios like Customer, Logistics Execution,
Catalog and RFQ, Purchase Order, Financials, ForeCasting, Exchange Interactions.

Configuration time activities in Integration Directory:
Let us plan for a scenario where in our XI system acts as receiver of the message and partner system sends
an Invoice message. That is Partner is starting a message exchange with XI.
Therefore a Sender CIDX adapter needs to be configured which is considered to be Single Action
Initiator.
1. Create a Party: Party represents a larger unit, which is involved in a cross-system process, for
example a Seller Company. Communication Parties are assigned alternative identifiers; across the
world with identifiers. (for example, Dun & Bradstreet D-U-N-S number).
Create two parties, one representing Buyer (initiator) and other Seller (Responder), EDI_XML_Buyer
and EDI_XML_Seller respectively.

2. Create a Service: Business Service represents an abstract, addressable unit. Business services are
used in cross-company processes. CIDX adapter determines the partners service name and local
service name for an incoming CIDX message based on Service Header fields as described below:
Service Name should be as CIDX<TransactionCode>_Version_PartnerRole.
<Transaction Code>:= /ServiceHeader/ProcessControl/ProcessIdentity/GlobalProcessIndicatorCode
Transaction Code: For every business transaction, CIDX standards have defined unique Code to
identify the transaction and process it accordingly. A sample code list is provided earlier in this
document.
<Version>:= /ServiceHeader/ProcessControl/ProcessIdentity/VersionIdentifier
<Partner Role>:=
/ServiceHeader/ProcessControl/TransactionControl/PartnerRoleRoute/fromRole.PartnerRoleDescrip
tion/GlobalPartnerRoleClassificationCode
<Current Role>:=
/ServiceHeader/ProcessControl/TransactionControl/PartnerRoleRoute/toRole.PartnerRoleDescriptio
n/GlobalPartnerRoleClassificationCode
For example:
Buyer service should be named as CIDXE81_40_Buyer
Seller service should be named as CIDXE81_40_Seller
Find below the sample message containing the information as described above.

3. Create a Communication channel of type CIDX adapter:
As partner is initiating the message select the adapter type as Sender.
For understanding more about the parameters of CIDX adapter while configuring them, go
throughhttp://help.sap.com/saphelp_nw04/helpdata/en/02/265c3cf311070ae10000000a114084/f
rameset.htm


4. Create a Sender Agreement using the communication channel created for this Scenario within this
agreement.

5. Create other objects to complete the configuration which includes Receiver Determination, Interface
Determination and Receiver Agreement.
6. An effort is also made to discuss Security Services in CIDX Adapter:
XI and RNIF protocols support message level security by digital signature and encryption. Message-
level security processing is done in Java part of SAP WAS.
CA (Certificate Authority) certificates to be used need to be entered into Key Store of J2EE Engine
that executes the security handling at runtime.
During configuration these certificates are referred while defining the communication channels when
certificate logon is used.
Otherwise, UserName/Password authenticity can be used alternatively.
There are three sections to achieve the security of transmission of the messages between chemical
companies
a. Confidentiality: Select HTTPS communication protocol
b. Authentication, Authorization and Message Integrity: By digitally signing the message
authenticates the receiver to receive the message. Validation is done by the receiver to
match the identity of the sender. Then message is processed successfully to achieve the
integration of Business.
c. Accountability:
i. Non-Repudiation of the message when selected for inbound messages means that
partner cannot deny of sending the messages and stores the inbound message in
the security archive.
ii. Non-Repudiation of the message when selected for Outbound messages means
that partner cannot deny or receiving the messages and stores the outbound
message in the security archive.
Testing Results:
Message is sent by Company A which needs to be received by XI of Company B.
Chem. XML message with Preamble, ServiceHeader, Service Content and Digitally signed is
received by Adapter Engine. When this message is monitored through Messaging system, viewed as
below:
Message ID 7a451b3102e112ddc6e975b43570eb8c
RefToMsgID

Conversion ID PROCESS.HFO7w7WYcCkcu6FKTUEpnSs4cQ9Vg.Invoice.CompanyA
Sequence Number 0
Message Type Asynchronously Received Message (RECEIVE)
From Party Name: EDI_XML_CompanyA
From Service Name: CIDXE81_40_Buyer
Action Namespace http://sap.com/xi/CIDX/40 Name: Invoice
Connection Name CIDXAdapter
Status Delivered
Error Category

Error Code

Profile CIDX
Transport HTTPS
Delivery Semantics Exactly Once
Times Failed 0
Number of Retries 5
Sent/Received 04/25/2008 12:00:00
Transmitted/Delivered 04/25/2008 12:00:49
Next Delivery 04/25/2008 12:00:00
Persist Until 04/25/2008 12:00:00
Valid Until

Retry Interval 5 Minutes
Address https://yhsapi01:50300/MessagingSystem/receive/CIDXAdapter/CIDX
Credential

Transport Headers Content-Length = 10234 HTTP=POST
Node ID 2082666
From the above one can observe that status is delivered and other message details are provided.
CIDX adapter with the available details from the chem. XML message does following
o Validates the digital signature with the action message
o Using the service header information
DUNS number of sender, receiver identifies Sender and Receiver Party
Transaction code, version, Requesting Message and Partner Roles identifies
Sender and Receiver Business Services
o Converts chem. XML message to SOAP message encapsulating content as XML message
derived from Service content
Routes the message to Integration Engine and is processed by Pipeline Services.









Chem XML Message eStandards and CIDX Scenario - Part III
By Suraj Kumar Pabbathi
In my earlier blogs efforts are made to explain about CIDX standards, how to design and configure the object
to support CIDX communication.
Blog1: http://saptechnical.com/Tutorials/XI/ChemXML/part1.htm
Blog2: http://saptechnical.com/Tutorials/XI/ChemXML/part2.htm
I would like to make your experience pleasant and fruitful with CIDX communication through this blog.
This blog covers those intricate details in regard to security, certificates through simple steps, focusing on PI
7.1
You have already selected CIDX adapter with Transport Protocol as "HTTPS" and Message Protocol as
"RNIF 1.1" for communication. Selecting the message protocol to RNIF 1.1 means you are configuring the
scenario to handle Preamble, Service Header, Service Content, Digital Signatures etc...
We will focus on achieving HTTPS communication which is a combination of HTTP with SSL/TLS protocol to
provide encrypted communication and secure identification of a network web server.
Step 1: Since the CIDX adapter is available through adapter engine, you need to set your server through
Java stack to receive and send secured messages.
SSL Communications are handled by ICM (Internet Communication Manager) for both the Java and ABAP
servers. You need to perform the configuration to use one of it, navigate to RZ10, select the profile
<SYSID>_DVEBMGS00_<host> and configure the profile parameter.
ssl/pse_provider = JAVA
Step 2: Restart the server to notice automatic creation of Keystore views in SAP NetWeaver Administration
(NWA).

Navigate to NWA >> Configuration Management >> Certificate and Keys.
Identify the new Keystore View named after ICM_SSL_<instance ID>
Create the private key in the specified keystore view using "Create" and follow the wizard.

Notice that "Generate CSR Request" is enabled and use it generate CSR Request. Basically this step is
needed to get your certificate issued by 3
rd
party Authority, to be identified as secure partner to carry out
secure online transactions and conduct the business over internet.
When you purchase the certificate that is considered as CSR Response. Select the private key that you have
just created and import it as "Import CSR Response".
Copy these certificates into Trusted CAs and secure_ssl keystore Views.
Step 3: Load the public key of your partner with entire certificate chain (Public Key, Intermediate and Root)
into keystore Views "ICM_SSL_XXXX", Trusted CAs.
In the following screenshot, you can view Verisign as Certificate Authority and chain of certificates.
They can be recognized as Verisign as root, Verisign Class 3 Secure Server CA G3 as intermediate and
business.partner.com as public key.

At times your partners provide self signed certificates, however PI supports.
























Chem XML Message eStandards and CIDX Scenario - Part III
...Previous
Step 4: Choose how you want to enable your partner log into your server to come up with processing a
message request.
a) In some cases, the certificate is issued with CN = <user id>, then provide necessary authorizations to the
user.
b) In most cases, the certificate is issued after host name for eg., business.partner.com. In this case to
support the certificate log in, you need to perform additional settings.
i. Create a certificate user say PICERTUSER with adequate authorizations (One of it is XI_AF_RECEIVE).
ii. Navigate to NWA >> Configuration Management >> Security >> Authentication
Go to Login module, ClientCertLoginModule.
Edit to maintain Name as Rule1.getUserFrom and Value as wholeCert.

iii. Navigate to NWA >> Configuration Management >> Security >> Identity Management.
Display PICERTUSER, Modify to load the partner certificate(Only Public key).

It basically means when message comes from remote server, certificate is authenticated and then accept to
login through PICERTUSER.
Internally the message is checked whether valid or not by comparing the certificate Authority in
ICM_SSL_XXX and partner through TrustedCAs. If it exists, it passes and then next part of steps is to select
the matching user with the certificate.
iv. As an additional optional step, you may want to restrict the processing of scenario to this user through
Business component >>Assigned Users in Configuration.

Step 5: Follow my previous blog 2 for configuration.
Wait for another blog that focuses on Troubleshooting CIDX communication.
For additional help use SAP resources
1. CIDX
Adapterhttp://help.sap.com/saphelp_nwpi711/helpdata/en/90/1d17c56bb01f4382342294b9a4a308/f
rameset.htm
2. Maintaining the Users Certificate Information
http://help.sap.com/saphelp_nwpi711/helpdata/en/a7/1cd08ffe25e34799cbbe1a7ecdb8ed/frameset
.htm
3. You may use diagtool provided by SAP, more details are available in note#1045019 Web Diagtool for
collecting traces. This is a very good tool that provides you the visibility on how the message is being
processed.