baseline naming conventions - region syddanmarknami… · web viewthe following naming convention...

Naming Conventions

Version: 1.6Date: 2006-02-07

Project: Baseline Version: 1.6Document: document.doc Date: 2006-09-26

Table of contents

1 INTRODUCTION.................................................................................................................................. 3

1.1 GENERAL DESCRIPTION...................................................................................................................... 31.2 REVISION HISTORY............................................................................................................................ 31.3 REFERENCE DOCUMENTS.................................................................................................................... 31.4 ABBREVIATIONS................................................................................................................................ 3

2 WHAT’S NEW IN THIS VERSION?...................................................................................................4

2.1 THE DOCUMENT IS STRUCTURED ACCORDING TO THE BASELINE CONCEPT MODEL..............................42.2 THE INTEGRATION CONCEPT IS STRINGENTLY DEFINED.......................................................................42.3 THE SERVICE CONCEPT HAS BEEN INTRODUCED..................................................................................42.4 THE NAMING CONVENTION FOR TRAFFIC FROM THE INTEGRATION PLATFORM TO A RECEIVING APPLICATION IS REVERSED............................................................................................................................ 42.5 THE .IN AND .OUT EXTENSIONS IN QUEUE NAMES HAVE BEEN DEPRECATED......................................52.6 THE QUEUE TYPE QUALIFIERS HAVE BEEN DEPRECATED......................................................................52.7 WMB MESSAGE SETS ARE NAMED AFTER A SERVICE, NOT A CONTRACT............................................52.8 SOME ARTIFACTS ARE NO LONGER COVERED BY THE NAMING CONVENTIONS.......................................5

3 GENERAL GUIDELINES..................................................................................................................... 6

3.1 NAMING STRUCTURE......................................................................................................................... 63.2 USING DELIMITERS IN NAMES.............................................................................................................63.3 RECOMMENDED CHARACTERS............................................................................................................ 63.4 CASE................................................................................................................................................ 63.5 BRAND NAME IN NAMING CONVENTIONS...........................................................................................63.6 CONVENTIONS................................................................................................................................... 7

4 NAMING CONVENTIONS WHEN CREATING AN INTEGRATION..............................................8

4.1 INTEGRATIONS.................................................................................................................................. 84.2 SERVICES.......................................................................................................................................... 94.3 CONTRACTS.................................................................................................................................... 10

5 NAMING CONVENTIONS FOR WMQ OBJECTS..........................................................................11

5.1 GENERAL GUIDELINES..................................................................................................................... 115.2 QUEUE MANAGERS.......................................................................................................................... 115.3 SENDER/RECEIVER CHANNELS.......................................................................................................... 125.4 QUEUES.......................................................................................................................................... 135.5 MQ SCRIPTS.................................................................................................................................... 165.6 CLUSTERS....................................................................................................................................... 17

6 NAMING CONVENTIONS FOR WMB OBJECTS...........................................................................19

6.1 CONFIGURATION MANAGER............................................................................................................. 196.2 BROKER.......................................................................................................................................... 196.3 MESSAGE FLOWS............................................................................................................................. 196.4 MESSAGE SETS................................................................................................................................ 20

7 NAMING CONVENTIONS FOR ICS/WBI EXPRESS OBJECTS...................................................21

7.1 BUSINESS OBJECTS.......................................................................................................................... 217.2 COLLABORATIONS........................................................................................................................... 237.3 MAPS.............................................................................................................................................. 267.4 RELATIONSHIPS AND PARTICIPANTS..................................................................................................27

8 Document Naming Convention............................................................................................................ 30

2 (31)


1 Introduction

1.1 General descriptionThis document lays out the naming conventions used in the Baseline Integration Platform.

1.2 Revision HistoryVersion Date Description Author1.0 - Created1.1 2005-04 Added naming conventions for

WBI Express & Interchange Server

1.2 2005-10-13

Adapted to Baseline 3.0 Martin Rydman

1.3 2005-11-07

Added some remarks, and made some changes, regarding delimiter in names.Added Naming Convention for WMB Configuration Manager

Martin Rydman

1.4 2006-02-07

Added naming convention for MQ scripts

Martin Rydman

1.5 2006-02-15

Changed Acceptance test environment to Quality Assurance Environment

Martin Rydman

1.6 2006-09-26

Replace period (.) with underscore (_) in Configuration manager and Broker names

Martin Rydman

1.3 Reference documents

Document name VersionBaseline Concept Model.doc

1.4 Abbreviations

WMB WebSphere Message Broker

3 (31)


WMQ WebSphere MQ

ICS Interchange Server

4 (31)


2 What’s new in this version?2.1 The document is structured according to the Baseline Concept Model

You will find the naming conventions for concepts (such as Integrations, Services, and Contracts) in a separate section, and the various technology-based naming conventions (such as WMQ, WMB, and ICS) in separate sections.Read more about the concepts in Baseline Concept Model.doc.

2.2 The Integration concept is stringently definedThe new definition will encourage objects that lend themselves to being reused, while maintaining the Integration concept as the primary structure. This leads to some new features:

One Integration may use objects that are part of another Integration. As an example, se next bullet

When using the Route To Queue functionality, the RTQ flow and associated WMQ objects are now considered parts of a separate Integration, leading to a different naming of those objects (see Queue names in a generalized routing scenario below)

2.3 The Service concept has been introducedThis has a few implications on naming conventions for queues and flows. For an example of this, see next section (2.4).

2.4 The naming convention for traffic from the Integration Platform to a receiving application is reversed

In previous versions of Baseline, the naming convention stipulated one exit point for a flow, and that the Contract-specific queue was located on the external server:

In this version of Baseline, the Contract-specific alias queue is the one the Consumer (Order Processor) is writing to:

5 (31)


Since more than one exit point is now allowed, the problem of how to name the outbound queues when more than one queue is needed (e.g., routing) is solved. It is also a natural consequence of the new Service concept.

2.5 The .IN and .OUT extensions in queue names have been deprecated

This is a natural consequence of the previous items (2.3 and 2.4)

2.6 The queue type qualifiers have been deprecatedNo distinction in the queue name is made between local, alias and remote queues.

2.7 WMB Message sets are named after a Service, not a Contract

A Message format is now a property of a Service, and since the WMB Message set implements a Message format, its naming convention has been altered.

2.8 Some artifacts are no longer covered by the naming conventions

From experience, it has been proved impractical to impose naming conventions for the following artifacts:

PoD’s Message Types

6 (31)


3 General guidelines3.1 Naming structure

Baseline aims at collecting and structuring all objects (documents, queues, message flows etc.) within an Integration. Three major concepts constitute the backbone of the naming structure:

Read more about these (and other) concepts in Baseline Concept Model.doc.

3.2 Using delimiters in namesBaseline recommends period (.) as delimiter in all names. Some objects (like some WMB-files) won’t allow a period in their name. In those cases, use an underscore (_).

3.3 Recommended charactersNames should contain letters, numbers, and a delimiter, such as period (.). Spaces and special characters (e.g., %, -, /, \) are not recommended.

3.4 CaseConceptual names (Integrations, Services, and Contracts) should be on the form PurchaseOrder, sometimes referred to as UpperCamelCase. This means that each separate word in a name begins with a capitalized letter. All other letters are lower case (except for abbreviations, such as XML).

3.5 Brand name in Naming ConventionsIn this document you will see ZYS being used for brand name and three digits being used for sequence number. Feel free to adapt the length of the parts to suit specific needs. You can also append some grouping indicator to the brand name. For example, ZYS.ABC could group together all Integrations in the ABC project within the ZYS organization.Since the decisions made regarding brand name and serial number will trickle down to MQ objects (such as queue managers and channels), the combined length of the two should not be greater than 7 characters.

7 (31)


3.6 ConventionsIn this document, some typographic conventions apply:

<DESC> <> denotes text that should be substituted with relevant content

[.] [] denotes an optional element{.} {} denotes a deprecated elementX|Y Choose one (X or Y)

8 (31)


4 Naming conventions when creating an Integration4.1 Integrations

ZYS{IS}001.<DESC>ZYS

Brand Name Zystems

{IS}001 Serial number of the Integration.<DESC> Description of the Integration

ZYS{IS}001 is the Integration ID, which is the base for the naming of all other entities in the Integration.An Integration (as defined in Baseline Concept Model.doc) should concern itself with one data type. This data type should be reflected in the description part of the Integration name.

ExamplesZYS001.Order Contains all Contracts and Services that concerns an

Order. This is an example of a business-oriented Integration.

ZYS099.Mail Contains all Contracts and Services that concerns the sending of Mail notifications. This is an example of an infrastructure oriented Integration.

When deciding a high-level name for an Integration, it might be a good idea to consider the fact that within a large enterprise, several kinds of Orders or Customers might exist. Therefore, a qualified name, such as PurchaseOrder or SalesOrder, might be a better choice. Baseline considers anything going on in an Integration Platform as part of an Integration. This means that completely generic Services in the platform, such as a generic router, would be considered part of an Integration handling the data type Message. Such an Integration would probably not get a name containing the data type, but rather a descriptive name of what it does, such as RTQ (Route To Queue).

9 (31)


4.2 ServicesZYS{IS}001.<DESC>ZYS

Brand Name Zystems

{IS}001 Serial number of the Integration that contains this Service

.<DESC> Description of the Service

The Service performs an operation on the relevant data type in a particular format1. A recommended structure of the <DESC> part is:

<DESC> <verb><format><data type><verb> Should indicate what the Service does<format> Should indicate in what specific format <data type> is

expected<data type> Should be the same as the <DESC> part of the

Integration name

This naming scheme is by no means mandatory or exhaustive. Some situations will call for deviations from the scheme (see the SendMail Service below for an example)

ExamplesZYS001.PutXMLOrder Performs the Put operation on an Order in XML

formatZYS099.SendMail Performs the Send operation on a Mail (note that

the <format> part is missing)

1 WSDL defines a Service as a set of operations on a data type. The Baseline Concept Model does not have a specific Operation concept as such, but an actual Baseline Service could implement several Operations.

10 (31)


4.3 ContractsZYS{IS}001[.]A.<DESC>ZYS

Brand Name Zystems


[.]A Serial letter (A, B, C…). Use double letters (AA, AB, AC…BA, BB, BC…) if many Contracts are required. Note! The ContractID (ZYS{IS}001[.]A) must be unique within the integration.

.<DESC> Should be the same as the name of the Service it accesses

ExamplesZYS001A.PutXMLOrder

A Contract that defines how a particular Consumer invokes the PutXMLOrder Service

ZYS099A.SendMail A Contract that defines how a particular Consumer invokes the SendMail Service

11 (31)


5 Naming Conventions for WMQ Objects5.1 General guidelines

WebSphere MQ names should follow the conventions for WMQ, rather than the standard for object names on each supported platform, as object names may need to be used across platforms.

Don't use lower case lettersWMQ allows both upper and lower case letters in its names.However, WMQ names are case-sensitive and this may cause errors as some tools convert strings to upper case.

Don't use % in namesThis character is valid in all WMQ names. However, it is not commonly used in other names across platforms.

Choose meaningful names, within the constraints of the conventionsThe Service and Contract naming conventions should always be the primary source of WMQ names (as outlined in Queues below). In cases where this is not feasible, meaningful names should be used.

Always include a DescriptionAll objects have a DESCR attribute for this purpose. WMQ takes no action on the value, but allows it to be viewed.

5.2 Queue ManagersThe Queue Manager Name should be max 8 characters

ZYS001D|T|QZYS Brand Name Zystems001 Serial Number for the Queue ManagerD|T|Q Environment

D = Development EnvironmentT = Test EnvironmentQ = Quality Assurance (QA)EnvironmentIf this is excluded it denotes the Production Environment.

ExampleZYS002D QueueManager at Zystems(ZYS).

12 (31)


Serial Number 2 (002) in Development Environment (D)

ZYS001T QueueManager at Zystems(ZYS). Serial Number 1 (001) in Test Environment (T)

ZYS003Q QueueManager at Zystems(ZYS). Serial Number 3 (003) in QA Environment (Q)

ZYS004 QueueManager at Zystems(ZYS). Serial Number 4 (004) in Production Environment

5.3 Sender/receiver channels<FROM QUEUE MANAGER>.<TO QUEUE MANAGER>[.N]<FROM QUEUE MANAGER> The Sending Queue Manager. Separator Between sending Queue

Manager and receiving Queue Manager

<TO QUEUE MANAGER> The receiving Queue Manager[.N] Serial Number if there is more than

one Channel between two Queue Managers

Example:ZYS001T.ZYS002T Channel sending information from

Queue Manager ZYS001T to Queue Manager ZYS002T.

ZYS002T.ZYS003T.1 The second channel sending information from Queue Manager ZYS002T to the Message Broker Queue Manager ZYS003T.

13 (31)


5.4 Queues

Local, Remote, and Alias queues The name of Local, Remote, and Alias queues should be max 48 characters. The first 15 characters of the queue name should be unique within the queue manager.No distinction is made between these queue types. The reason for this is that switching from one set-up to another (e.g., when moving from a non-clustered to a clustered environment) often entails changing queue types. If no queue type qualifiers are used, all queue names can stay the same in the new set-up.

Capitalizing WMQ namesSince WMQ objects should be capitalized, the UpperCamelCase names (e.g. PurchaseOrder) must be capitalized. The recommendation is to insert a period (.) between the different words: PURCHASE.ORDER.

Contract-specific queuesZYS{IS}001[.]A[.<DESC>]ZYS

Brand Name Zystems


[.]A Serial letter (A, B, C…)[.<DESC>] Should be the same as the name of the Contract

(capitalized)

ExampleZYS001A.PUT.XML.ORDER

A Contract-specific queue for the ZYS001A.PutXMLOrder Contract

Service-specific queuesZYS{IS}001.<DESC>{.IN}|{.OUT}ZYS

Brand Name Zystems


.<DESC> Should be the same as the name of the Service (capitalized)

{.IN} Denotes a queue feeding messages to a Message flow.

14 (31)


Deprecated.{.OUT} Denotes a queue receiving messages from a Message

flow. Deprecated. Not applicable if the new Service concept is used.

ExampleZYS001.PUT.XML.ORDER A Service-specific queue for the

ZYS001.PutXMLOrder Service

Example scenariosAll examples below assume a typical clustered scenario, where alias queues are used to route messages to/from the Integration platform. If a non-clustered scenario is used, alias queues in the examples can be substituted with remote queues.

Queue names derived from Services and ContractsBaseline considers all message exchanges (on a conceptual level) to involve a Service Consumer and a Service Provider:

In the picture above, two Consumers access the same Service (ZYS001.PutXMLOrder) via two Contracts (ZYS001A.PutXMLOrder and ZYS001B.PutXMLOrder). The Service’s Endpoint (a local queue) is named as the Service. Following the general WMQ guidelines above, the queue name is capitalized, and the period delimiter is inserted to separate the different parts of the Service description.Likewise, the Contract-specific alias queues get their names from the Contract names (capitalized and with the different parts delimited with a period).Looking at the traffic from the Integration platform to a receiving application, we have full symmetry:

15 (31)


Here, the Order Processor is now considered a Consumer, accessing the ZYS001.PutOAGISOrder Service through its own Contract (ZYS001C.PutOagisOrder).

16 (31)


Queue names in a generalized routing scenarioConsider a scenario where Application A (e.g., an ERP system) has a generic channel to the Integration platform, i.e. it will send any data type (Orders, Customer etc) to the same Endpoint in the Integration platform: EMBED Visio.Drawing.11

In this case, note how Application X is directly involved only in the ZYS999.RTQ Integration using a Contract named accordingly. The Routing Service, in turn, will partake in two other Integrations (ZYS001.Order and ZYS002.Customer).

Queue names in a request-reply scenario

In this case the Price Processor Service might inspect a Reply To Queue property of the request message and put the reply on the local Contract queue on Server A.

Queue names in a point-to-point scenarioIn cases where the sole purpose of an Integration is to transfer a file from one application to another, the Service name (and consequently the Service Endpoint name) may only contain the data type, omitting an operation name:

17 (31)


Dead Letter Queue The name of all dead letter queues should be:

SYSTEM.DEAD.LETTER.QUEUE

Exception and Back-out Queue The default name for the Integration platform general back-out queue is:

BASELINE.BACKOUTFor Integration/application specific exception queues the literal BACKOUT should be appended to the queue name.

ExampleZYS001.PUT.XML.ORDER.BACKOUT

A Service-specific backout queue for the ZYS001.PutXMLOrder Service

Transmission Queue The transmission queue should follow the name of the channel. The name should equal the last part of the Channel: <To Queue Manager>[.N]

ExampleChannel Transmission QueueZYS001T.ZYS002T ZYS002TZYS001.ZYS006 ZYS006ZYS001.ZYS006.1 ZYS006.1

5.5 MQ ScriptsZYS{IS}001_<DESC>.mqscZYS

Brand Name Zystems


.<DESC> Should be the same as the name of the Contract (capitalized)

ExampleZYS001_Order.mqsc Contains all MQ objects specific to the

ZYS001_Order Integration for a particular Queue Manager

18 (31)


5.6 ClustersZYSC00XZYS Brand Name ZystemsC Denotes a cluster00 Serial Number for the clusterX Environment

D = Development EnvironmentT = Test EnvironmentQ = Quality Assurance (QA) EnvironmentIf this is excluded it equals the Production Environment.

ExampleZYSC001T The first cluster in the test environment

Alias queue managersThe naming convention for alias queue managers used to route into clusters is:

ZYS.CLUSTERS.XZYS.CLUSTERS Alias queue manager prefixX Environment

D = Development EnvironmentT = Test EnvironmentQ = Quality Assurance (QA) EnvironmentIf this is excluded it equals the Production Environment.

ExampleZYS.CLUSTERS.T Routes to all test clusters

Cluster channelsThe naming convention for cluster receiver channels:

TO.<Cluster name>.<Queue manager name>ExampleTO.ZYSC001.ZYS012 The cluster receiver channel on the

QM ZYS012 for the cluster ZYSC001Cluster sender channels must be named as the receiver counter-part.

19 (31)


6 Naming Conventions for WMB objects6.1 Configuration manager

In WMB 6.0, the Configuration Manager is given a name. It is not applicable in earlier versions.

CM._<QUEUE MANAGER NAME>ExampleCM_ZYS001T Configuration Manager in test

EnvironmentCM_ZYS001 Configuration Manager in production

Environment

6.2 BrokerBK_<QUEUE MANAGER NAME>ExampleBK_ZYS001T Broker in test EnvironmentBK_ZYS001 Broker in production Environment

6.3 Message flowsA Message flow implements a Service, and should be named accordingly:ZYS{IS}001_< DESC>ZYS Brand Name Zystems{IS}001 The identity of the Integration_<DESC> Same as the Service name

Note that Message flow file names can’t contain a period.ExampleZYSIS001_PutXMLOrder.esql ZYSIS001_PutXMLOrder.msgflow

Message flow files implementing the ZYSIS001.PutXMLOrder Service

Message flow projectsAppend the literal _Flow to the Message flow project name.

ExampleZYSIS001_PutXMLOrder_Flow A Message flow project that contains the

flow that implement the ZYSIS001.PutXMLOrder Service.

20 (31)


6.4 Message SetsA Message set implements a Message (which is a property of a Service), and should be named accordingly:

ZYS{IS}001_< DESC>ZYS Brand Name Zystems{IS}001 The identity of the Integration_<DESC> Same as the Service name, without the

verbNote that Message set file names can’t contain a period.ExampleZYS001_XMLOrder A Message set that implements the

Message of the ZYS001.<verb>XMLOrder Service(s)

Completely generic Message sets that implement industry standards, such as EDIFACT or SWIFT, should not be named according to a specific integration. These are truly reusable artifacts, and should be named after the industry standard and data type they implement.

ExampleEDIFACT.D97A.ORDERS A Message set that implements the

EDIFACT D97A ORDERS message

Message set projectsAppend the literal _Mset to the Message set project name.

ExampleZYSIS001_XMLOrder_Mset A Message set project containing the

Message set that implements the Message format of the ZYS001.<verb>XMLOrder Service(s)

21 (31)


7 Naming Conventions for ICS/WBI Express objectsThe following naming convention is recommended to be used for WebSphere Business Integration Express and Interchange Server. It is based on the IBM WebSphere Interchange Naming components document and adapted to Baseline guidelines.

Note that ICS/WBI Express limit the use of period (.) as delimiter. Therefore underscore (_) is used throughout this section.

7.1 Business Objects

Generic Business Object2

Top-level business objects<GenericObjectName>ExampleCustomer The Customer GBOItem The Item GBO

The generic business object name should accurately identify the type of entity it represents and should not contain spaces. If the entity cannot be described in one word, concatenate all the meaningful words into one, using UpperCamelCase style (a capital letter beginning each word).

Child business objects[GenericObjectName]<ChildObjectName>[GenericObjectName] The top-level object. Use this when the

child object is specific to the top-level object, i.e. not reusable in any other context.

<ChildObjectName> The child object

ExampleCustomerProfile A child object (Profile) to top-level object

(Customer)Address A child object (Address) not qualified by a

top-level object

2 Note that although the general naming scheme would suggest that the General Business Object (GBO) is identical to the Integrations data type, and therefore be named accordingly, the way GBO’s are dealt with in ICS makes this unpractical, and consequently, Baseline sticks with the IBM recommendations in this regard.

22 (31)


Application Specific Business Object

Top-level business objects ZYS{IS}001_<APPLICATION|FORMAT>_<DataType> ZYS Brand Name Zystems{IS}001 The identity of the Integration_<APPLICATION|FORMAT> Application specific Adapter:

Use the applications name (capitalized), e.g. SAPTechnology AdapterUse a format name (capitalized), e.g. XML

_<DataType> The DataType used. This might contain application specific qualifiers, such as version

DataType should be as faithful as possible to the application's terminology and differ from it only if the application uses phrasing that is not useful (for example, if the application assigns the name DataTable1 to the table that contains its customer data, you might consider naming the business object Customer instead of DataTable1).

ExampleZYS001_SAP_Order A SAP Order participating in the ZYS001

IntegrationZYS005_CLARIFY_BillingRecord A Clarify BillingOrder participating in the

ZYS005 Integration

Child business objects<TopLevelBusinessObject>_<ChildObjectName><TopLevelBusinessObject> The Top Level Business Object as defined

above<ChildObjectName> The name of the child object

ExampleZYS001_SAP_Order_OrderLine An OrderLine child object to the

ZYS001_SAP_Order objectZYS005_CLARIFY_BillingRecord_BillingLine

A BillingLine child object to the ZYS005_Clarify_BillingRecord object

23 (31)


Business Object Attributes

<ApplicationFieldName>|<AdaptedApplicationFieldName> < ApplicationFieldName > The exact field name from the

application's schema< AdaptedApplicationFieldName >

The field name from the application adapted to the IBM WebSphere business Integration naming style

ExampleContact_customer_id Exact field nameContactCustomerId Adapted field name

7.2 Collaborations

Collaboration template

<GenericObjectName><Function> < GenericObjectName > The GenericObject the template handles< AdaptedApplicationFieldName >

The function the template provides

If the name is more than one word, concatenate the words using UpperCamelCase style. The combined length of the name of a collaboration template and that of its triggering port (internal or external) may not exceed 80 characters.

Note: Make sure the template name is different from the collaboration object it processes. If the names are the same, you cannot access the collaboration object using repos.copy with the -e (Entity) option because repos.copy searches for the collaboration template before searching for a collaboration object.

ExampleCustomerSync A template providing the Sync function

for the Customer objectCustomerWrapper A template providing the Wrapper

function for the Customer object

24 (31)


Collaboration object

ZYS{IS}001_<CollaborationName>_<SRCAPPLICATION(S)>_to_<DESTAPPLICATION(S)> ZYS Brand Name Zystems{IS}001 The identity of the Integration_< CollaborationName > The Collaboration template_<SRCAPPLICATION(S )> The Source application(s) (capitalized). If

more than one, separate each with __to_<DESTAPPLICATION(S)> The Destination application(s)

(capitalized). If more than one, separate each with _

This naming convention is beneficial particularly for tracing information during troubleshooting. Including the identity of the integration and applications involved helps to indicate which integration and applications that are affected by a specific problem. Including the flow direction helps to distinguish problems between two collaborations created for bidirectionality. Including the template on which the object is based helps to distinguish one process from other processes that might exist between identical applications and identical directionality.The combined length of the name of a collaboration object and that of its triggering port (internal or external) may not exceed 80 characters.

Note 1: Make sure the collaboration object name is different from the template name that processes it. If the names are the same, you cannot access the collaboration business object using repos.copy with the -e (Entity) option because repos.copy searches for the collaboration template before searching for a collaboration object.

Note 2: Be sure that the collaboration object names are consistent within a site. In a request/response scenario the source application should be seen as the application making the request and the destination application should been seen as the receiver of the request and the provider of the response.

Example: ZYS001_CustomerSync_CLARIFY_to_SAP

A Collaboration based on the CustomerSync template sending data from Clarify to SAP

ZYS003_ItemSync_Oracle_to_SAP_JDEDWARDS_ORACLE

A Collaboration based on the ItemSync template sending data from Oracle to SAP, JDEdwards, and Oracle

25 (31)


Collaboration ports

From|To|DestAppRetrieve| To<ReferencedObjectName>Wrapper|SrcAppRetrieve

From The port that receives the incoming business object and triggers the flow

To The port through which the primary business object of the collaboration is sent to the destination application

DestAppRetrieve The port through which the collaboration retrieves data in the destination application to compare it to the source business object

To<ReferencedObjectName>Wrapper

The port through which a reference-valued business object is sent for processing by a grouped collaboration object (recommended naming convention for extending a collaboration to delegate an object to a wrapper)

SrcAppRetrieve The port through which business object data is retrieved from the source application For multiple-destination ports, add a number to the end of the port name.

26 (31)


7.3 Maps

Top-level maps

Application-specific-to-generic map <ApplicationSpecificTopLevelObjectName>_to_<GenericTopLevelObjectName> Example: ZYS001_SAP_CustomerMaster_to_Customer

Maps the application-specific business object ZYS001_SAP_CustomerMaster to the generic Customer business object.

Generic-to-application-specific map <GenericTopLevelObjectName>_to_<ApplicationSpecificTopLevelObjectName> Example: Order_to_ZYS002_CLARIFY_SFAQuote

Maps the generic Order business object to the ZYS002_CLARIFY_SFAQuote application-specific business object.

Submaps

Application-specific-to-generic submap Sub_<ApplicationSpecificObjectName>_to_<GenericTopLevelObjectName>_<ChildObjectName> Example: Sub_ZYS001_SAP_Order_OrderLineItem_to_Order_OrderLineItem

Maps the application-specific business object Sub_ZYS001_SAP_Order_OrderLineItem to the generic Order_OrderLineItem business object.

Generic-to-application-specific submap:Sub_<GenericTopLevelObjectName>_<ChildObjectName>_to_<ApplicationSpecificObjectName> Example: Sub_Order_OrderLineItem_to_ZYS001_SAP_Order_OrderLineItem

Maps the application-specific business object Sub_ZYS001_SAP_Order_OrderLineItem to the generic Order_OrderLineItem business object.

27 (31)


Polymorphic maps

Application-specific-to-generic polymorphic map Poly_<ApplicationSpecificObjectName>

Polymorphic maps can be complex. Not only should their names clearly indicate every generic business object that the application-specific business object maps to, but the names should be consistent within a site. Remember that polymorphic map names have an 80-character limit, so use abbreviations if necessary.

Example: Poly_ZYS001_CLARIFY_PartRequest

Routes the application-specific business object Poly_ZYS001_CLARIFY_PartRequest to the correct map object.

Generic-to-application-specific polymorphic mapPoly_<GenericObjectName>Example: Poly_Order Routes the generic business object

Poly_ZYS001_CLARIFY_PartRequest to the correct map object.

Reply maps

<ApplicationSpecificTopLevelObjectName>_to_<GenericTopLevelObjectName>_Reply

To distinguish reply maps from top-level maps the map name should be followed by the suffix .Reply.

Example: ZYS001_SAP_CustomerMaster_to_Customer_Reply

Maps the reply of the application-specific business object ZYS001_SAP_CustomerMaster to generic business object Customer.

7.4 Relationships and participants

Identity

Identity relationships associate the unique identifiers of application entities. There is only one unique identifier for any object and therefore only one relationship instance in an identity relationship for it.

Identity relationships<Name that reflects the generic business object>

28 (31)


Name the relationship so that it reflects the generic business object that the application-specific business objects are transformed to during mapping. Relationship Designer imposes an eight-character limit on identity relationship names: use the full generic object name if it is eight or fewer characters; abbreviate the name or parts of the name if it is more than eight characters.

Example: Customer Associates objects involved with the

generic Customer object OrderLine Associates objects involved with the

generic OrderLineItem object

Identity participants<APPNAME>|<GBO><GenObjectName>

Relationship Designer imposes an eight-character limit on participant names:

<APPNAME>|<GBO> A maximum of four characters for the application name (capitalized). For generic participants, start with the two-letter abbreviation GBO.

<GenObjectName> A four-letter abbreviation for the business object name.

Example: SAPCustGBOCustCLARQuln

LookupLookup relationships associate fields that contain similar data across different applications, but are often represented in different formats.

Lookup relationships<GenObjectName>

There may be multiple lookup relationships for any object, so it is inappropriate to name the relationship after the object. Instead, consider naming a lookup relationship after the attribute in the generic business object to which attributes in the application-specific business objects are mapped.

Note: Even though you do not create a participant for the generic object in a lookup relationship, IBM recommends that you use the name of a generic business object as the name of the relationship to indicate the type of data to be referenced.

29 (31)


The objective is to name the relationship in such a way that suggests what the data represents but in a way that is not application-specific. That is typically how a generic object's attribute is named as well. Therefore, you can use the attribute name as the name of the lookup relationship.

State Associates different application formats for representing state information in an address

Country Associates different application formats for representing country information in an address

Currency Associates different application formats for representing currency information

Lookup participants<APPNAME><AttrName>

Relationship Designer imposes an eight-character limit on participant names:

<APPNAME> A maximum of four characters for the application name (capitalized).

<AttrName> A four-letter abbreviation for the attribute name in the application-specific business object.

Example: CLARStat Represents the State field in ClarifySAPCtry Represents the Country field in SAPORACCrcy Represents the Currency field in Oracle

30 (31)


8 Document Naming ConventionAll documents are named on the form:

<Template name> - <Entity name>.docExamples Baseline Integration Specification - ZYS001.Order.doc

Integration Specification covering the ZYS001.Order Integration

Baseline Contract Specification – ZYS001A.PutXMLOrder.doc

Contract Specification covering the ZYS001A.PutXMLOrder Contract

Baseline Test Protocol - ZYS001.Order.doc

Test Protocol covering the ZYS001.Order Integration

31 (31)

baseline naming conventions - region syddanmarknami… · web viewthe following naming convention...

Documents