In this section: |
Native services are services provided by the NME service engine as a layer for accessing data persisted in NME. These services may be called directly or through an integration component such as PME. The actual service names and parameters are derived directly from the data model.
Services are configured in the nme-services.gen.xml file. It contains two main elements:
For example:
<serviceConfig> <services> <service class="com.ataccama.nme.internal.engine.services.handlers.GetInstanceBy IdServiceBundle"/> <service class="com.ataccama.nme.internal.engine.services.handlers.GetMasterById ServiceBundle"/> <service class="com.ataccama.nme.internal.engine.services.handlers.TraverseMaster ServiceBundle" /> <service class="com.ataccama.nme.internal.engine.services.handlers.Generic TraversalMasterService"/> <service class="com.ataccama.nme.internal.engine.services.handlers.ListInstances ServiceBundle" /> <service class="com.ataccama.nme.internal.engine.services.handlers.ListMasters ServiceBundle"/> <service class="com.ataccama.nme.internal.engine.services.handlers.Search InstancesServiceBundle" /> <service class="com.ataccama.nme.internal.engine.services.handlers.SearchMasters ServiceBundle" /> <service class="com.ataccama.nme.internal.engine.services.handlers.IdentifyMaster Service" entity="party_mas" masterLayer="gen" name="identifyPartyGen" /> <service class="com.ataccama.nme.internal.engine.services.handlers.ProcessDelta Service" /> </services> <endpoints> <endpoint class="com.ataccama.nme.internal.engine.services.endpoints.HttpEndpoint" pathPrefix="/soapOverHttp/*" listenerNames="nmeNative"> <format class="com.ataccama.nme.internal.engine.services.endpoints.SoapFormat"/> </endpoint> <endpoint class="com.ataccama.nme.internal.engine.services.endpoints.JmsEndpoint" pathPrefix="/xmlRpcOverJms/*"> <format class="com.ataccama.nme.internal.engine.services.endpoints.XmlRpcFormat" />
<connectionName>ActiveMQ</connectionName> <inputDestination>MQ_in</inputDestination> <outputDestination>MQ_out</outputDestination> </endpoint> </endpoints> </serviceConfig>
The above configuration shows all available data-related native services. The services will be available through defined endpoints at http://localhost:8888/[pathPrefix]. Endpoint is referring to listener(s) (defined in the main server configuration file, usually serverConfig.xml) in the listenerNames attribute.
A list of services provided by the current instance of NME is accessible through the web console (click MD Interfaces and then select Services) or direct link: http://localhost:8888/console/nmeInterfaces/services. In case of SOAP services, the list of available services is available at http://localhost:8888/soap/. The WSDL per each shown service is also available.
NME native services are available on configured endpoints in configured formats. NME supports the following endpoints:
NME also supports the following formats:
NME supports all four combinations of these formats and endpoints.
HttpEndpoint allows calling native services using standard HTTP protocol. The following configuration creates an HttpEndpoint attached to listener nmeNative providing services on http://<serverAddress>:<listenerPort>/soapOverHttp:
<endpoint class="com.ataccama.nme.internal.engine.services.endpoints.HttpEndpoint" pathPrefix="/soapOverHttp/*" listenerNames="nmeNative"> <format class="com.ataccama.nme.internal.engine.services.endpoints.SoapFormat" /> </endpoint>
If the format is SOAP, the WSDL services will be available on http://<serverAddress>:<listenerPort>/soapOverHttp.
JmsEndpoint allows accessing native services using JMS. It requires the JmsProviderComponent server component. The following configuration creates a JmsEndpoint connected to a JMS server, defined in an ActiveMQ connection (the configuration is in JmsProviderComponent). The endpoint reads requests from destination MQ_in and sends responses to destination MQ_out, as shown in the following syntax.
<endpoint class="com.ataccama.nme.internal.engine.services.endpoints.JmsEndpoint" pathPrefix="/xmlRpcOverJms/*"> <format class="com.ataccama.nme.internal.engine.services.endpoints.XmlRpcFormat" serviceNameHeader="SOAPJMS_soapAction" /> <connectionName>ActiveMQ</connectionName> <inputDestination>MQ_in</inputDestination> <outputDestination>MQ_out</outputDestination> <outputParameters> <outputParameter name="stringParamName" value="stringValue" type="STRING"/> <outputParameter name="intParamName" value="123" type="INT"/> <outputParameter name="longParamName" value="10010101001012" type="LONG"/> <outputParameter name="booleanParamName" value="false" type="BOOLEAN"/> </outputParameters> </endpoint>
where:
Is the name of the connection defined in the JmsProviderComponent in the server configuration file.
Is the destination from which the endpoint is reading requests.
Is the destination to which the endpoint is sending responses.
Allows you to add some additional information into the JMS properties (for example, header).
Optional attributes pathPrefix and listenerNames have the same meaning as for HttpEndpoint, but are used only for SoapFormat to configure the location where the WSDL is available.
For XmlRpcFormat under JmsEndpoint, the serviceNameHeader is used to define what header contains the name of service. The default is SOAPJMS_soapAction.
This section describes all NME services. The following examples are for XmlRpcFormat. For SoapFormat, you can get a WSDL or you can change examples as shown in the following syntax (the example is for getExampleInstanceById):
XmlRpc Example
<request> <id>1</id> </request>
SOAP Example
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:get="http://www.ataccama.com/ws/nme/getExampleInstanceById"> <soapenv:Header/> <soapenv:Body> <get:getExampleInstanceById> <get:id>1</get:id> </get:getExampleInstanceById> </soapenv:Body> </soapenv:Envelope>
For the rest of this section, a dummy instance entity Example, a dummy master entity Example, and a dummy Master View Mv will be used to illustrate the functionality of services.
This section lists and describes the read-only services.
Sample Requests
The getEntityInstanceById service is called with the following input:
<request> <id>1</id> </request>
and can return the following syntax:
<getentityInstanceByIdResponse> <entity> <metadata> <id>1</id> <originId>origin_id</originId> <sourceSystem>source_system</sourceSystem> <active>false</active> <creationTid>123</creationTid> <lastUpdateTid>111</lastUpdateTid> <creationDate>2013-02-19T10:51:03+01:00</creationDate> <lastUpdateDate>2013-02-22T09:07:48+01:00</lastUpdateDate> </metadata> <attributes> <source_id>100</source_id> <master_id>2</master_id> .... .... </attributes> </entity> </getentityInstanceByIdResponse>
Sample Requests
The getExampleMvById service is called with the following input:
<request> <id>1</id> </request>
and can return the following syntax:
<getExampleMvByIdResponse> <ExampleMv> <metadata> <id>1</id> <active>true</active> <creationTid>10</creationTid> <lastUpdateTid>11</lastUpdateTid> <creationDate>2013-02-19T10:44:13+01:00</creationDate> <lastUpdateDate>2013-02-19T10:48:14+01:00</lastUpdateDate> </metadata> <attributes> <pty_key_mas>100</pty_key_mas> <dsid>123</dsid> <ref_eng_active>true</ref_eng_active> <ref_allowed_flg>false</ref_allowed_flg> </attributes> <relationships/> </ExampleMv> </getExampleMvByIdResponse>
The two basic features are:
Sample Requests
<request> <startWith entity="Party" id="322" /> <preloadedRelationships> <rel name="Party_Address" /> <rel name="Party_Party_Contract_role/Contract_Party_Contract_role_rev" /l> </preloadedRelationships> </request> <request> <startWith entity="party" originId="s1#Party" sourceId="2021" /> <traversal> <traverse relationshipName="contracts"> <filter> <eq attribute="std_status" value="active" /> <exists> <traverse relationshipName="products"> <!-- traverse to contract depending on values on related entity product --> <filter> <eq attribute="std_type" value="fund" /> </filter> </traverse> </exists> </filter> </traverse> <traverse relationshipName="products" /> <!-- traverse further from contract to product --> </traversal> <preloadedRelationships> <rel name="party" /> <rel name="products" /> </preloadedRelationships> </request>
where:
Is the Indentification of the record from which the traversing/preloading starts. The record is identified either by ID (ID on master layer contains the <master_id> value) or by the combination of originId and sourceId.
Is the name of the entity from which the traversing/preloading starts (required).
Is the NME primary key of the record.
Is the Identification of the source (for example, KP_climp_in#Party)
Is the source primary key of the record.
Are the relationships preloaded in the response (for example, entities joined by the relationships listed are included in the response).
Is the name of the relationship preloaded (for example, <rel>Party_address</rel>).
Note: Relations are oriented. If multiple relations are preloaded in a single path, they are separated by a slash (/). For example, <rel>Party_Party_Contract_role/Contract_Party_Contract_role_rev</rel>
Is one or more traversals along the relationships defined in the model.
Is the traversal definition
Is the name of the relationship traversed (for example, <t relationshipName="Party_Address" />).
Filtering, by default, are eq and exists subelements evaluated as AND. It can be set to OR (operator="OR"). The same works in filter for preloadedRelationships. <eq> for example, <eq attribute="std_type" value="fund" />. <exists>
Sample Requests
The listaddressInstances service is called with the following input:
<request> <origin>crm#party</origin> <range> <offset>0</offset> <count>30</count> </range> <search> <city>Prague</city> <street>Main</street> </search> </request>
The syntax returns addresses which have the city column filled with Prague and the street column filled with Main. All search conditions needs to be satisfied.
The <origin> element (optional) is a special search criterion limiting the results to the records with the given origin.
The <range> element (optional) restricts the number of returned records. The default value is 100. The maximum allowed value is 100, but can be changed through Services.
The use is the same as in ListInstanceService, but the only difference is that the request cannot contain the element <origin>.
It works similarly as ListInstanceService, but the only difference is that you can use wildcard * (meaning any character(s)).
Sample Requests
The searchaddressInstances service is called with the following input:
<request> <origin>crm#party</origin> <range> <offset>0</offset> <count>30</count> </range> <search> <city>Prague*</city> </search> </request>
The syntax returns addresses which have column city filled with Prague, Prague 1 or ... .
The <origin> element (optional) is a special search criterion limiting the results to the records with the given origin.
The <range> element (optional) restricts the number of returned records. The default value is 100. The maximum allowed value is 100, but can be changed through Services.
The use is the same as in SearchInstanceService. The only difference is that a request cannot contain the <origin> element.
<service class="...IdentifyMasterService" entity="example" masterLayer="mv" name="identifyExampleMv" />
The service receives (as an input) attributes of the instance entity (one record), runs a cleansing and matching plan, and returns a matched master record. If the record is identified to any existing record(s) in already processed and stored data, it returns the matched master record. Otherwise, it returns an empty response.
Note: This requires you to enable the identify service in model.xml.
Sample Requests
The identifyEntityGen service can have the following input:
<request> <sourceSystem>system#1</sourceSystem> <record> <attributes> <src_first_name>Joe</src_first_name> <src_last_name>Black</src_last_name> <src_birth_num>1234567890</src_birth_num> </attributes> <relationships/> </record> <preloadedRelationships> <rel name="addresses" /> </preloadedRelationships> </request>
where:
Is the Source system identificator.
Is the record for which the master record should be identified
Are the attributes of the record for entity identification.
Makes it possible to return related entities (similar to GenericTraverseMasterService).
This section lists and describes the read-write services.
<service class="com.ataccama.nme.internal.engine.services.handlers. ProcessDeltaService" requiredRole="esb"/>
The input message consists of a sequence of elements (named after entities), each representing a single record updated in the transaction. For example, if a single Customer record and two Address records should be updated, the message will be:
<processDelta> <Party> ... </Party> <Address> ... </Address> <Address> ... </Address> </processDelta>
Each record element consists of several subelements, giving values of the columns/properties.
There are three system properties:
The remaining properties correspond to source columns defined on the entity.
The <origin> (the string with hashtags (#) identifying the source) and <source_id> (identifier from the source) properties are used to identify records in the same way as batch load interfaces.
The <change_type> property can be either I (insert), U (update, however, there is no difference between I and U in terms of processing since iWay MDS detects the proper value), D (deactivation of the record, logical delete), or X (real delete). Both delete operations have an equivalent in a batch interface setting. For more information, see Deletion Strategy.
Note: Autonomous setting is always used for all entities in the delta detection process. The delta detection setting from the batch load interfaces is ignored by the service.
<request> <Party> <origin>s2#Party</origin> <!-- origin --> <source_id>8021</source_id> <!-- identifier in origin/source system --> <change_type>I</change_type> <!-- insert or update --> <!-- data columns follow (derived from model) --> <src_name>John Smith</src_name> <src_inn>2985903432</src_inn> </Party> </request>
The response is a list of results per every sent record:
<processDeltaResponse> <recordList> <!-- contains one record element for every record in the input --> <record id="39096018" recordChange="INSERT" origin="s2#Party" sourceId="8021" /> <!-- id is not present below because change_type was X or D and record did not exist in the hub --> <record recordChange="NONE" origin="s2#Address" sourceId="782" /> </recordList> </processDeltaResponse>
where:
Is the engine internal record ID (usable in getInstanceBydIdService bundle).
Is the origin of the record sent in the input.
Is the sourceId of the record sent in the input.
<service class="com.ataccama.nme.internal.engine.services.handlers. ProcessUpsertService" requiredRole="esb" system="mdm" entity="party" />
Configuration Attributes
role. An optional parameter user role required to invoke the service, securing access to the RW capability.
system. Source system that is managed by the hub.
entity. An entity that is top level in the instance model service. The record of this entity is also the top level in input XML messages.
Sample Requests
Records are sent as hierarchical message, top level entity record must be always present. The input record consists of:
Note that origin is not required. It is defined by a combination of entities on input, and the system is configured in the nme-services.gen.xml file. The System is managed by the hub, and should have exactly one origin for every instance entity.
The following Request shows the syntax for inserting a new party with a related address record.
<party> <change_type>I</change_type> <attributes> <src_name>John Smith</src_name> <src_ssn>568934579</src_snn> </attributes> <relationships> <addresses> <address> <change_type>I</change_type> <attributes> <src_street>2 Green Street</src_street> <src_city>New York</src_city> <src_zip>67896</src_zip> </attributes> </address> </addresses> </relationships> </party>
The response is similar to processDeltaService. The service returns a record information of a created party record.
<processUpsertResponse> <recordList> <record sourceId="436" origin="mdm#party" id="39096018" recordChange="INSERT" /> </recordList> </processUpsertResponse>
Request to update party:
<party> <change_type>U</change_type> <source_id>436</source_id> <attributes> <src_name>John Smith Jr.</src_name> <src_ssn>568934579</src_snn> </attributes> </party>
Request to update address record must contain party envelope:
<party> <change_type>N</change_type> <!-- change_type N means Nothing, party records serves only as envelope for address record --> <source_id>436</source_id> <relationships> <addresses> <address> <change_type>U</change_type> <source_id>456</source_id> <attributes> <src_street>2b Green Street</src_street> <src_city>New York</src_city> <src_zip>67896</src_zip> </attributes> </address> </addresses> </relationships> </party>
Request to insert a new address to a given party must contain a party envelope:
<party> <change_type>N</change_type> <source_id>436</source_id> <relationships> <addresses> <address> <change_type>I</change_type> <attributes> <src_street>8596 Main Ave</src_street> <src_city>Washington</src_city> <src_zip>68349</src_zip> </attributes> </address> </addresses> </relationships> </party>
Request to delete address:
<party> <change_type>N</change_type> <source_id>123</source_id> <relationships> <addresses> <address> <change_type>D</change_type> <source_id>456</source_id> </address> </addresses> </relationships> </party>
The following rules apply:
The following table describes the asynchronous variant of RW services. Both RW services have asynchronous variants.
Synchronous Service |
Asynchronous Variant |
Get Result of Asynchronous Service |
---|---|---|
processDelta |
processDeltaAsync |
processDeltaAsyncGet |
processUpsert<entity> |
processUpsert<entity>Async |
processUpsert<entity>AsyncGet |
Those services are automatically available with their synchronous variants. No extra configuration is required. These services are visible on the web console including the WSDL if appropriate (for SOAP format).
The difference between synchronous and asynchronous services are:
Sample response of processDeltaAsync:
<processDeltaAsyncResponse xmlns="http://www.ataccama.com/ws/nme/processDeltaAsync"> <taskId>1403</taskId> </processDeltaAsyncResponse>
Sample request to processDeltaAsyncGet:
<processDeltaAsyncGet> <taskId>1403</taskId> </processDeltaAsyncGet>
Sample response of processDeltaAsyncGet (result element has the same structure as the response of synchronous processDelta):
<processDeltaAsyncGetResponse xmlns="http://www.ataccama.com/ws/nme/processDeltaAsyncGet"> <id>601</id> <typeId>service.processDeltaAsync</typeId> <status>FINISHED_OK</status> <result> <recordList> <record id="401003" recordChange="NONE" origin="crm#customer#party"sourceId="34590835"/> </recordList> </result> </processDeltaAsyncGetResponse>
These services are located in the com.ataccama.nme.internal.engine.services.handlers.BatchControlServiceBundle service bundle. The services allow external applications to schedule load and export operations without the need to interact with the workflow component or parse the pages in the web console.
The service bundle has one parameter, requiredRole, that can (and should) be used to restrict access to the services.
<service class="com.ataccama.nme.internal.engine.services.handlers. BatchControlServiceBundle" requiredRole="remote" />
invokeLoadOperation
This operation invokes a load operation with the given parameters. The request consists of the operation name and an optional list of operation parameters.
Sample request:
<invokeLoadOperation> <name>crm_in</name> <!-- load operation name --> <parameters> <!-- zero or more parameters --> <parameter name="fileSuffix" value="20110812"/> </parameters> </invokeLoadOperation>
The service will return immediately, placing the operation into a task queue. The response consists of a single value, taskId, assigned to the task. The getTaskStatus service can be used to query the state of the task.
Sample response:
<invokeLoadOperationResponse> <taskId>4</taskId> </invokeLoadOperationResponse>
invokeMultiLoadOperation
Invokes a multi load operation with the given parameters. The request consists of list of operations' names and an optional list of operation parameters.
Sample request:
<invokeMultiLoadOperation> <operations> <operation>crm_full</operation> <operation>life_full</operation> </operations> <parameters> <parameter name="someParam" value="someValue" /> </parameters> </invokeMultiLoadOperation>
The service will return immediately, placing the operation into task queue. The response consists of a single value, taskId, assigned to the task. The getTaskStatus service can be used to query the state of the task.
Sample response:
<invokeMultiLoadOperationResponse> <taskId>4</taskId> </invokeMultiLoadOperationResponse>
invokeExportOperation
This operation invokes an export operation with the given parameters. The semantics of the request and response is the same as in the case of invokeLoadOperation.
Sample request:
<invokeExportOperation> <name>full</name> <!-- export operation name --> <parameters> <!-- zero or more parameters --> <parameter name="referenceTransactionId" value="6226117"/> </parameters> </invokeExportOperation>
Sample response:
<invokeExportOperationResponse> <taskId>12</taskId> </invokeExportOperationResponse>
getTaskStatus
For a given <taskId>, this retrieves the status details for that task.
Sample Request:
<getTaskStatus> <taskId>12</taskId> </getTaskStatus>
If the task is not found, then the response will contain the status with the value NOT_FOUND (other fields are empty). Otherwise, the structure containing the task ID, metadata, and status is returned. The status can be one of WAITING (task in queue), RUNNING (currently being executed), FINISHED_OK (finished successfully), FINISHED_FAILURE (finished with a failure), ABORTING (task has been cancelled by a user but has not yet terminated),or ABORTED (task has been aborted by a user).
Sample Response:
<getTaskStatusResponse> <id>12</id> <typeId>batchExport.full</typeId> <status>FINISHED_OK</status> </getTaskStatusResponse>
These services are located in the com.ataccama.nme.internal.engine.services.handlers.ModelStatiticsServiceBundle service bundle. The services provide statistics about data in the hub, or a count of active and inactive records for every entity. Records physically deleted in iWay MDS (records with eng_existing=0) are not counted nor displayed.
<service class="com.ataccama.nme.internal.engine.services.handlers.ModelStatistics ServiceBundle"/>
getInstanceStatistics
Returns a count of active and inactive records for every instance entity, in addition to every combination of source systems and instance entities. This service answers the question to the number of active party records from CRM systems in the hub.
The request is empty:
<getInstanceStatistics> </getInstanceStatistics>
Sample response:
<getInstanceStatisticsResponse> <entities> <entity inactive="0" name="party" active="32"> <systems> <system inactive="0" name="life" active="0"/> <system inactive="0" name="crm" active="32"/> ... </systems> </entity> <entity inactive="0" name="contract" active="0"> <systems> <system inactive="0" name="life" active="0"/> <system inactive="0" name="crm" active="0"/> ... </systems> </entity> ... </entities> </getInstanceStatisticsResponse>
getMasterStatistics
Returns a count of active and inactive records for every master entity. This service answers the question to the number of active master party records in the hub.
The request is empty:
<getInstanceStatistics> </getInstanceStatistics>
Sample response:
<getInstanceStatisticsResponse> <entities> <entity inactive="0" name="party" active="32"> <systems> <system inactive="0" name="life" active="0"/> <system inactive="0" name="crm" active="32"/> ... </systems> </entity> <entity inactive="0" name="contract" active="0"> <systems> <system inactive="0" name="life" active="0"/> <system inactive="0" name="crm" active="0"/> ... </systems> </entity> ... </entities> </getInstanceStatisticsResponse>
getMasterStatistics
Returns a count of active and inactive records for every master entity. This service answers the question to the number of active master party records in the hub.
The request is empty:
<getMasterStatistics> </getMasterStatistics>
Sample response:
<getMasterStatisticsResponse> <entities> <entity inactive="0" name="party" active="18" view="mas"/> <entity inactive="0" name="rel_party_party" active="3" view="mas"/> <entity inactive="0" name="contact" active="49" view="mas"/> <entity inactive="0" name="address" active="32" view="mas"/> </entities> </getMasterStatisticsResponse>
These services are located in the com.ataccama.nme.internal.engine.services.handlers.ReadWriteControlServiceBundle service bundle and are available only if VLDB persistence is used. They allow external applications to switch data access mode between RW and RO.
Note: Only one NME instance can operate on a DB storage in the RW mode at a time. An external application should guarantee this (otherwise data corruption and inconsistencies can occur). The service bundle has one parameter, requiredRole, that can (and should) be used to restrict access to the services.
Initial data access mode is defined by NME runtimes parameters. For more information, see NME Runtime Parameters.
<service class="com.ataccama.nme.internal.engine.services.handlers. ReadWriteControlServiceBundle" requiredRole="remote" />
switchReadWriteMode
This service starts the switch to the given target mode.
Sample request:
<switchReadWriteMode> <targetMode>RO</targetMode> <!-- target mode can be RO (read-only) or RW (read-write) --> <switchMode>WAIT</switchMode> <!-- must be WAIT in this version, reserved for future use --> </switchReadWriteMode>
The service will return immediately, and starts the switch action asynchronously. The response contains either OK and current mode, or ERROR and an error message (if the start of switch failed).
Note: The OK response does not mean the switch will be successful. The switch action is complex and can fail after response.
A switch to RO waits for completion of the active RW operation (load, export, processDelta). The switch to RW checks the transaction state of the NME storage and can perform a recovery.
Sample response:
<switchReadWriteModeResponse> <result>OK</result> <message>SWITCHING_TO_RO</message> <!-- if switch has already finished, message is "RO" --> </switchReadWriteModeResponse>
getReadWriteMode
Returns the data access mode of this NME instance. The request is empty.
Sample request:
<getReadWriteMode> </getReadWriteMode>
The service will return the current data access mode, which can be one of the following:
Sample response:
<getReadWriteModeResponse> <readWriteMode>RO</readWriteMode> </getReadWriteModeResponse>
This service bundle provides detailed information on underlying MDM hub data model. Services are read only and the model cannot be changed this way.
<service class="com.ataccama.nme.internal.engine.services.handlers.ModelServiceBundle" />
getModel
The service retrieves complete MDM hub data model (all entities and their relationships, master views, dictionaries, and so on). The request is empty.
Sample request:
<getModel/>
Sample response:
<getModelResponse> <instanceLayer> <entities> ... <entity name="address"> <columns> <column name="id" type="LONG_INT"/> <column name="source_id" type="STRING" size="1000"/> <column name="master_id" type="LONG_INT"/> <column name="party_source_id" type="STRING" size="200"/> <column name="src_type" type="STRING" size="2000"/> <column name="std_type" type="STRING" size="30"/> <column name="exp_type" type="STRING" size="500"/> <column name="sco_type" type="INTEGER"/> <column name="dic_type" type="STRING" size="30"/> <column name="src_street" type="STRING" size="2000"/> <column name="cio_street" type="STRING" size="100"/> <column name="src_city" type="STRING" size="2000"/> <column name="cio_city" type="STRING" size="100"/> <column name="src_state" type="STRING" size="2000"/> <column name="cio_state" type="STRING" size="100"/> <column name="src_zip" type="STRING" size="2000"/> <column name="cio_zip" type="STRING" size="100"/> <column name="exp_address" type="STRING" size="500"/> <column name="sco_address" type="INTEGER"/> <column name="cio_address_comp" type="STRING" size="1000"/> <column name="meta_last_mod_date" type="DATETIME"/> <column name="uni_can_id" type="LONG"/>
<column name="uni_rule_name" type="STRING" size="100"/> <column name="uni_role" type="STRING" size="10"/> <column name="party_master_id" type="LONG_INT"/> </columns> <relationships> <relationship parentEntity="party" name="party" parentKeyColumn="source_id" childEntity="address" childKeyColumn="party_source_id"/> </relationships> </entity> <entity name="rd_address_type"> <columns> <column name="id" type="LONG_INT"/> <column name="source_id" type="STRING" size="1000"/> <column name="master_code" type="STRING" size="1000"/> <column name="master_name" type="STRING" size="1000"/> </columns> <relationships/> </entity> ... </entities> <sourceSystems> <system name="crm"/> <system name="life"/> <system name="hub_reference_data"/> </sourceSystems> </instanceLayer> <masterLayer>
<masterView name="masters"> <entities> ... <entity name="address"> <columns> <column name="id" type="LONG_INT"/> <column name="party_master_id" type="LONG_INT"/> <column name="cmo_type" type="STRING" size="30"/> <column name="cmo_street" type="STRING" size="100"/> <column name="cmo_city" type="STRING" size="100"/> <column name="cmo_state" type="STRING" size="100"/> <column name="cmo_zip" type="STRING" size="100"/> </columns> <relationships> <relationship parentEntity="party" name="party" parentKeyColumn="id" childEntity="address" childKeyColumn="party_master_id"/> <relationship parentEntity="address" name="instances" parentKeyColumn="id" childEntity="address_instance" childKeyColumn="master_id"/> </relationships> </entity> ... <entity name="rd_gender"> <columns> <column name="id" type="LONG_INT"/> <column name="source_id" type="STRING" size="1000"/> <column name="master_code" type="STRING" size="1000"/> <column name="master_name" type="STRING" size="1000"/> </columns>
<relationships> <relationship parentEntity="rd_gender" name="master_codes_cmo_gender" parentKeyColumn="master_code" childEntity="party" childKeyColumn="cmo_gender"/> </relationships> </entity> </entities> </masterView> ... </masterLayer> </getModelResponse>
iWay Software |