Sources properties
Use the Configuration editor > Member Types > Sources tab in InfoSphere® MDM Workbench to add and remove definitional sources.
The following table describes the properties you can define for sources.
| Property | Description |
|---|---|
| Default Entity Priority | Use this setting to prioritize entity management by source.
The allowable values are 0 - 32767. The lower the number, the higher
the entity manager processing priority. For example, a source with
an Entity Priority of 1 is processed before a source with priority
2. If you do not want to enable entity management priority, set all
of your sources to the same value, such as 0. When entity management
by source is disabled, the default behavior is for entity management
processing to be done in create time order (caudRecno). Do not confuse setting entity management source priority with source priority, which is used to determine trusted source linking. With regards to trusted source linking, the entity manager determines which members must be re-crossmatched if a trusted source record links or unlinks. These members have entity records created and inserted into the entity manager queue. When the records are created, they use the same entity management priority as their linked trusted source member. For example, if a record from Source A is linked to trusted source record B, the priority setting for B is used for the entity manager re-queue. Default: 100 |
| Enable Review Identifier Task | Indicates whether records from this source are compared for Review Identifier tasks. |
| Is virtual? | Indicates whether the source is virtual. Member attributes from virtual sources are not written to the operational server database, but do participate in derived data. By setting this field to Y, you are indicating that all attributes that come from this source are treated as virtual and are not available for display in task and member searches. A Y setting in MPI_srchead overrides the isVirtual setting of N in MPI_SegAttr (virtual attributes). For more information about virtual settings, see the statement that follows this table. |
| Physical code | A physical code provides a way to group sources, but does not affect operational server processing. For example, a hospital can have separate source systems for the laboratory, registration desk, and pharmacy. This code enables a grouping of these systems under one physical umbrella, yet retains a different source code identifier for each system. |
| Potential overlay comparison code | The comparison function used for overlay comparison. This code is found in MPI_cmphead. If no function is selected, potential overlay comparison is disabled. |
| Potential overlay score | The overlay comparison score; a negative number. Records from this source that score below this number are placed in Potential Overlay tasks. The software assumes a decimal. For example if you enter -10, the software converts the score to -1.0. |
| Record status | Indicates whether the source is Active (in use) or Inactive. Selecting Inactive does not prevent source-to-source comparisons against records from this source. An inactive status prevents inserts (adds), updates, and deletions to an inactive source. If a source is marked inactive and an interaction is attempted, an error is returned. |
| Source code | This code is used as a prefix on all source-assigned record numbers from this source in InfoSphere MDM software. You can use uppercase letters, numbers, and underscores in the source code. Source codes can be up to 12 characters in length. Workbench automatically trims off any characters over the limit of 12. Using the example of RMC as the source code and a record number of 880189, the full record source identifier would be RMC:880189. |
| Source name | Name of this source. |
| Srcrecno | A read-only field that contains the SRCRECNO field from the operational server database. |
Issues such as limitations on data storage capacity can lead to the use of virtual sources; member data not being stored in the operational server database or only in derived data form. Keep in mind when marking sources (or attributes) as virtual:
- Because virtual attributes are not stored in the core attribute tables, attribute history is not maintained. To search or compare on historical attributes, you must send in all values (current and historical) for a virtual attribute on every update.
- Because the data is stored in derived format only, you cannot easily reload the data for upgrades. During an upgrade, you must reload the virtual data from the source.