Open Framework, Information Management Strategy & Collaborative Governance | Data & Social Methodology - MIKE2.0 Methodology
Wiki Home
Collapse Expand Close

Members
Collapse Expand Close

To join, please contact us.

Improve MIKE 2.0
Collapse Expand Close
Need somewhere to start? How about the most wanted pages; or the pages we know need more work; or even the stub that somebody else has started, but hasn't been able to finish. Or create a ticket for any issues you have found.

CMM Messages created in Metadata Repository Deliverable Template

From MIKE2.0 Methodology

Share/Save/Bookmark
Jump to: navigation, search
Under construction.png
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.

Once the CMM Subjects have been identified, a CMM Message is created which encapsulates the required CMM Subjects and additional CDEs that may not be part of a Subject. These CMM Messages model the information that will flow between systems and will be used by Services in the run-time environment.

The key aspects of CMM Message creation process are as follows:

  • Definition of CMM Messages starts by creating an empty schema file from which we reference the CMM Subjects and/or CDEs. An empty schema file is first created for the placeholder for the CMM Message.
  • The CMM Message references the CMM Transaction Header. Every CMM Message must have a transaction header included as this holds message specific information such as transaction time, an identifier for the message and so on which are required as metadata for a message.
  • The Message enlists CMM Subjects and/or CDEs required for the CMM Message CMM Subjects and/or CDEs are chosen that relevant in creating the CMM Message. To create an Address Change CMM Message, for example, a Customer Reference Subject that holds the customer identifier, Account Reference Subject that holds the account identifier and Address List Subject which holds the new address would be used. We then create grouping/hierarchies using the enlisted components.
  • CMM Messages should be built to be environment independent. This ensures that the CMM Messages are independent of the developing environment and will allow us to port the CMM Messages to other environments (Testing, Staging and Production).

After CMM Messages have been loaded to the central metadata repository, they are reviewed by the Information Development team.

Contents

= Examples

Listed below are example CMM Messages: forfait sosh rio b and you portabilité du numéro calcul IMC rio orange

Example 1 - Creation CMM Messages – Work Instruction Details

Steps involved in creating a CMM Message:

1. Create a new schema (XSD) document - Here we are talking about creating an empty schema file from which we reference the CMM Subjects and/or CDEs.

2. Reference CMM Transaction Header – Every CMM Message must have a transaction header included as this holds message specific information such as transaction time, an identifier for the message and so on which are required as metadata for a message.

3. Enlist CMM Subjects and/or CDEs required for the CMM Message - Choose the CMM Subjects and/or CDEs that are relevant in creating the CMM Message. For instance, if you were to create an ’Address Change’ CMM Message you would include a ’Customer Reference’ Subject that holds the customer identifier, ’Account Reference’ Subject that holds the account identifier and ’Address List’ Subject which holds the new address.

4. Define grouping/hierarchies for the enlisted components – We then create grouping/hierarchies using the enlisted components.

5. Enable environment independence – This ensures that the CMM Messages are independent of the developing environment and will allow us to port the CMM Messages to other environments (Testing, Staging, Production).

6. Label the CMM Message – Finally, we need to add a name for the CMM Message.

Save the schema document – This completes the creation of a CMM Message

Example 2 - CMM MESSAGE: customer details

Request Data Stream Requirements:

CMM Attributes Null Option CDE Map Description
Customer Reference Subject  
Account Reference Subject  
Billing Inquiry      
Billing Start Date Not Null BILLING_STATEMENT_HISTORY.BILLING_STATEMENT_Period_Effective_Date Start date for retrieving billing details.
Billing End Date Not Null BILLING_STATEMENT_HISTORY.BILLING_STATEMENT_Period_Effective_Date End date for retrieving billing details.
Call History Inquiry     Query for Call History based on the start and end date as well as the Call History Type = Bill Complaints
Call History Start Date Not Null EVENT.EVENT_Start_Date Start date for retrieving call history details.
Call History End Date Not Null EVENT.EVENT_End_Date End date for retrieving call history details.
Call History Type Not Null EVENT_REASON.EVENT_REASON_Title Holds "Bill Complaints"
Call History Summary     Query for Call History Summary based on the start and end date. It is implicit that the Call History Summary is for all Call History Type.
Call History Summary Start Date Not Null EVENT.EVENT_Start_Date Start date for retrieving call history details.
Call History Summary End Date Not Null EVENT.EVENT_End_Date End date for retrieving call history details.

Issues:

Assumption:

  • Billing details are retrieved based on an Account. If Account Reference Empty, provide Billing/Call history for all accounts for the customer.
  • Call History Type holds "Bill Complaints".

Response Data Stream Requirements:

CMM Attributes Null Option CDE Map Description
Customer Reference Subject
Account List
Account Reference Subject
Contact History Subject
Contact History Summary Subject
Billing History List  
Billing Summary  
Billing Effective Date BILLING_STATEMENT_HISTORY.BILLING_STATEMENT_Period_Effective_Date  
Billing Due Date BILLING_STATEMENT_HISTORY.BILLING_STATEMENT_Period_End_Date  
Billing Statement Charge History Subject
Customer Value History Subject

CMM MESSAGE: ADDRESS IDENTIFICATION

Request Data Stream Requirements:

CMM Attributes Null Option CDE Map Description
Address List Subject

Issues:

  • None.

Assumption:

  • Assuming request data stream could hold one or more Address Details – for instance batch processing address identification process. The response may contain multiple Address Ids - a one to one mapping to the input Address Details.

Response Data Stream Requirements:

CMM Attribute Null Option CDE Map Description
Address List     List of addresses.
Address     Single address
Address ID     Returned Address ID from ADBor
Confidence Factor      
Wiki Contributors
Collapse Expand Close