Using CCTS in PI 7.1
I have had the opportunity to get access to a PI 7.1 system for a Demo-For-Prospect. Based on some of the experiences from this project, I will try to blog some of the details I get into.
One of the interesting aspects of the PI 7.1 is the way it is possible to use CCTS (Core Components Technical Specification) to define data types. By using CCTS it should be possible to have more reuse of data types. The reuse should result in a global directory of the different object, which will make it easier for to make mappings and user interfaces, because all have the same way to look at a part of the document i.e. an address.
I will in this blog describe how to use CCTS in PI 7.1 like how to define and reuse to data types. I will not go into detail with naming conventions, which as fair as I can see something which have to been decided how to use. To good sources of information is “How to Solve the Business Standards Dilemma the Context Driven Business Exchange” and How to Solve the Business Standards Dilemma – The CCTS based Core Data Types by Gunther Stuhec.
After creating a software component link it to SAP Basis 7.10 as an Installation Time component. This will enable the use of the data types defined in the SAP Basis component.
In the SAP Basis component there is an example of how the sales model from SAP will look in this format. The rest of the SAP Basis component only contains some generic components like BusinessDocumentMessageHeader or PhoneNumber. I would therefore expect that there will delivered more software component, which contains data types defined for other processes.
I would like to show how to create a service interface for a purchase order, in some limited format to show the different ways to model a service. After modeling the service we would like to end up with a XML document which looks like the following.
We will start with creating the OrderID as a core data type, since it has not been created in the document.
We will limit the number of attributes and change the pattern to Numeric. This data type could be used in the purchase order as well as the invoice.
Then we will create the party, which is going to be used. This is created as an Aggregated Data Type. In this data type to sub elements will be defined; Contact and Address. They are both linked to an Aggregated data type defined in the SAP Basis component. The first is BusinessPartnerElement and the other is the Address Element. This will give a definition as below.
We then want to create a lineitem element. This done the same way as the BusinessPartner, but for this we have to define our core datatypes, since they have not been defined in the SAP Basis component.
To create the ProductID we have to create a list of the different code, we want to be able to use. This is a Core Data type of term Code, where we remove all attributes by selecting the add/remove button. It is possible to specific which values this code list can contain.
The ProductID will then look like the following.
It is now possible to finish the LineItem element to the following.
We can then assemble the full document to the following.
It is a lot more time consuming to use the CCTS model, than to use the free style ways as used in PI 7.0. But it gives some extra value. It is easier to make reuse of components and there is the option of defining more strict rules for the data types. After having used a little time with the CCTS data types it is easier to create them and not a lot more over head with using the types.
The place I think the biggest issue will be how to perform governance on the model and create and following a naming convention. A place to see this could be to see how the example data types are defined and then use it as a foundation for creating new elements.
It is not possible to use a freestyle element in an aggregated data type, but the other way around it is possible to connect the data type. I guess that it therefore should be decided when to use CCTS or freestyle pr software component.