Model Driven Mural/MDM - Configuration Files

Having figured out how to use code generation from UML in Netbeans we'll now have to find out how a Mural MDM Application is configured before we can then move on to developing the templates for generating the configuration.

This article assumes that you are familiar with MDM. If you need to get a quick start with Mural MDM I'd recommend watching this tutorial.

The basic configuration files are highlighted in the project structure screen shot below:

Here's a short introduction to each file (in-depth information on MDM configuration files):

File name

Description

References Data Model

master.xml

configures Matching Process e.g. threshold for matches and potential duplicates.

No

mefa.xml

configures Matching Service, e.g. fields used for matching, normalisation of fields

Yes

midm.xml

configures Master Index Management Console (MIDM), e.g. search forms available and fields on results pages

Yes

midm-security.xml

containsweb application security for MIDM: authorised operations for user roles

No

object.xml

defines the MDM data model. Artefacts like jav API, database stcripts are generated form this file

Yes

query.xml

defines the queries that are used by the matching process and the MIDM

Yes

security.xml

configures security for the Java API/EJB of the MDM application

No

update.xml

defines update strategy used in the application (how the single best record is calculated)

Yes

validation.xml

configures validatiion components that are applied to data received by the MDM application

No

codelist.sql

defines list of values for fields (object.xml specifies which fields use a "codelist" or list of values)

Yes

Let's look at those files that contain configuration relevant to the data model in more detail.

object.xml

This file describes the data model of the MDM application.An Enterprise Object defined in MDM is a composite of objects. However the data model is limited to one parent and one level of child elements. A typical example would be a CustomerEO composed from Customer and Address as well as Phone childs. However it is not possible to further decompose the Adress object into a businessAddress and homeAddress object.

Let's have a look at some of the information in this file:

  • <nodes> elements define the data entities used in the application such as patient, address, phone number, visits in healthcare or customer, address, credit card in retail.

  • Its <tag> sub element defines the name of the entity

  • <fields> define the attributes of an entity including their name, type, size/length, part of primary key and list of values if appropriate (e.g. for a gender or title attribute)

  • Finally the <relationships> element defines the root entity and it's children

Most of the information in the file is a description of an object model in the OO sense – some of the information is database oriented (length of attribute, date format used by the objects ...) - which means most of the information required in objex.xml can be derived directly from a UML class diagram:

  • Classes and relationships (composition)

  • Attributes of classes, data types of attributes

Some other information like list of values, length can be added to UML components via tagged values or stereotypes.

midm.xml

Defines the appearance of the MDM management console. It consists of two main sections:

  • <node> element which is the object definition in terms of how it should be presented in the GUI, e.g. order on forms, type of control (TextBox, DropDownList etc.). This is very similar to object.xml above so it is clear how this information can be derived from UML also with the help of tagged values.

  • <gui-definition> lists all the different pages that will be available in the MIDM (Master Index Data Management) web application. Out of the box there is a start/dashboard type page plus a number of search form and result pages for the different searches MDM supports (alpha, phonetical, by Id). These page definitions indicate the attributes on the various pages and so refer back to the object model. Once again a UML model could indicate if attributes are searchable or should be displayed in result sets using tagged values or stereotypes.

mefa.xml

Defines which attributes should be normalized, standardized and/or phonetized. It also defines which attributes are used for matching records.

All of these sections define a set of attributes that should be transformed and mapped into another attribute. For example if first names are standardized the value in the first name attribute (Bill) will be transformed to its standardized form (William) and then stored in a “standardized first name” attribute.

A similar process (normalization) applies for free form texts for example addresses.

When matching data obviously these processed attributes should be used.

query.xml

Configures the query mechanisms used by MDM. There is some object model related data in here in the definition of blocker searches.

These blocker searches act as a crude set of filters for the match engine to identify possible duplicates for a record in a matching process. This is being used as a performance optimization – using block searches possible candidates are selected form the potentially large pool of data sets available. Then the matching engine can apply more sophisticated mechanisms to determine if the selected data sets constitue a possible match.

Attributes in the object model could be tagged as being used in such queries.

update.xml

Defines the calculation of the single best record (SBR) from the data supplied by different systems (System Records). Attributes of the object model are designated as being part of the SBR in this file.

codelist.sql

Should contain all the list of values referenced by “<code-module>” elements in object.xml. Lists are supplied in a straight forward way – codemodule name and values for the code module.

Part of this file could be derived from the UML model – attributes that use a list of values could be tagged as code-module.

Comments:

Post a Comment:
Comments are closed for this entry.
About

Swen, resident alien in the UK based part of a team at SUN called FAST

Search

Top Tags
Categories
Archives
« April 2014
MonTueWedThuFriSatSun
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Today