From MIKE2 Methodology
|
| This article is currently Under Construction. It is undergoing major changes as it is in the early stages of development. Users should help contribute to this article to get it to the point where is ready for a Peer Review.
|
| This deliverable template is used to describe a sample of the MIKE2.0 Methodology (typically at a task level). More templates are now being added to MIKE2.0 as this has been a frequently requested aspect of the methodology. Contributors are strongly encouraged to assist in this effort.
|
| Deliverable templates are illustrative as opposed to fully representative. Please help add examples to this template that are representative of the proposed output.
|
CMM Subjects are built to provide logical building blocks for creating CMM Messages. CMM Subjects are reusable assets that can be used in different CMM Messages (e.g. Address Subject, Customer Subject). These subjects are collections of CDEs that represent a business entity. The rationale behind CMM Subjects is to promote reusability within the system and simplify maintenance for the creation of CMM Messages. Building CMM Subjects involves the selection of the CDEs to be encapsulated in each logical entity into the metadata repository. The key aspects involved in creating CMM Subjects are as follows:
- Definition of the CMM Subject starts by specifying a name for referencing the CMM Subject in other CMM Subjects or in CMM Messages. An empty schema file is first created for the placeholder for the CMM Subject.
- CDEs are added to the schema for the CMM Subject by reference. Whilst they may not originally be from the same source system, all CDEs will come from the same centralised environment.
- CMM Subjects should be built to be environment independent. This ensures that the CMM Subjects are independent of the developing environment and will allow us to port the CMM Subjects to other environments (Testing, Staging, Production).
CMM Subjects should be refined and reviewed by the Information Development team before being made accessible for message creation.
Examples
Listed below are example CMM Subjects:
Example 1 - Creation of CMM Subjects and Messages – Work Instruction Overview
This solution will outline the process for the administration and creation of CMM subjects and CMM Messages. The solution will provide an easy to use user interface for creation and maintenance of CMM Components and CMM Messages.
The proposed CMM Message creation process is as follows:
Step 1 – Create CMM Subjects
- Design and build reusable CMM Subjects that can be used in different CMM Messages, for instance: Address Subject, Customer Subject and so on. These subjects are collections of CDEs to represent a business entity. Reason behind this is to promote reusability within our system and to provide easy maintenance for CMM Messages.
Step 2 – Create CMM Message
- Understand business requirement
Review business request and determine data requirement as this drives the creation of the CMM Message.
- Access existing components and build new Subjects
Based on the data requirements existing Subjects can be used to define the message data. If need be, a new Subject can be created as outlined in Step 1.
- Build CMM Message
Once the Subjects have been identified, a CMM Message is created which encapsulates the required Subjects and additional CDEs that may not be part of a Subject.
Step 3 - Exporting CMM Message to Runtime Environment
- Publish CMM Message
Involves transferring the created CMM Messages from XML Canon Repository to the Tibco Repository for run-time.
Note: The CMMs are independent of the application that uses them. In our example, we are using Tibco IM to send the messages.
Example 2 - for sample CMM Subjects created in Metadata Repository
SUBJECTS
CMM Subjects are logical encapsulation of Common Data Elements (CDE). They are created for usability and manageability
enabling re-use.
Customer Reference Subject
Description: References an Individual OR Organization that is represented either by an Enterprise ID or Individual ID or
Organization ID attributes. Enterprise ID, Individual ID and Organisation ID are all optional values.
| CUSTOMER REFERENCE SUBJECT
|
| CMM Attribute
| Null Option
| CDE Map
| Description
|
| Customer Reference
|
|
|
|
| Enterprise ID
|
|
|
|
| CIDN
|
| No mapping
| A Global Unique identifier for a customer.
|
| Party ID
|
| PARTY.PARTY_Identifier
| A unique identifier for any person or business that is of interest to the Communications Service Provider.
|
| Individual ID
|
|
|
|
| Last Name
|
| PARTY_INDIVIDUAL_NAME_HISTORY.PARTY_INDIVIDUAL_NAME_Last_Name
| The last name of the Party Individual.
|
| Birth Date
|
| PARTY_INDIVIDUAL.PARTY_INDIVIDUAL_Birth_Date
| The calendar day that an individual was born. Format: YYYY-MM-DD
|
| Drivers License
|
| PARTY_INDIVIDUAL.PARTY_INDIVIDUAL_Driver_Licence_Number
| The driver licence number that could be used to identify an individual.
|
| Organisation ID
|
|
|
|
| ACN
|
| PARTY_ORGANISATION.PARTY_ORGANISATION_National_Business_Number
| The National Business Number, as assigned for GST and other purposes.
|
| Organization Name
|
| PARTY_ORGANISATION_NAME_HISTORY. PARTY_ORGANISATION_Name
| The name used to recognize the Party Organization as a corporate entity.
|
Account Reference Subject
Description: Account Reference pertains to a unique identifier of an account in TDWI.
| ACCOUNT REFERENCE SUBJECT
|
| CMM Attribute
| Null Option
| CDE Map
| Description
|
| Account Reference
|
|
|
|
| Account Number
|
| ACCOUNT.ACCOUNT_Number
| A number used to identify a relationship between the Communications Service Provider and a Customer at the bill invoice level for Offerings subscribed to or used by that Customer.
|
| Account Type
|
| ACCOUNT_TYPE.ACCOUNT_TYPE_Title
| Business / Residential
|
| Account ID
|
| ACCOUNT.ACCOUNT_Identifier
| A sequence of digits used to identify an Account. An Account is a relationship between the Communications Service Provider and a Customer at the bill invoice level for Offerings subscribed to or used by that Customer.
|