This concept of operation for the Universal Data Element Framework (UDEF) applies to any organization that has the requirement to exchange data between applications, whether internal or external to the organization, and that cannot be adequately satisfied by an existing data standard.
As an example, Figure 1 shows each UDEF ID that was mapped to every data element concept in a government invoice transaction. When the data element concepts associated with the application that generates the invoice are also assigned a UDEF ID, mapping the data elements in a financial application to create the government invoice transaction would be greatly simplified. Once the data elements in a financial application have a UDEF ID, cost savings can be realized in creating other transactions using the same data elements for the same or different trading partners, regardless of the variations in data element names and structures that different trading partners may use.
If a data element concept cannot be mapped to the UDEF as it currently exists, then you may need extensions to the UDEF.
You should maintain a cross-reference matrix for mappings across disparate standards and applications.
The following example mapping matrix shows how the same data element concept, though named differently in each column, has the same UDEF ID. If all the data elements in all data standards and application interfaces were associated to a UDEF ID, mapping one data standard or application programming interface (API) to another would be greatly simplified and could be automated. See the row highlighted in blue, below, as UDEF ID = e.2_8 corresponding to Standard A name “Contract Document Identifier”.
Example Mapping Matrix
The following example shows how the UDEF helps a company to interpret information from external sources so that it can be processed by their applications.
Company A needs to send an XML file to Company B. Company B needs to process the data into their application using a flat file.
Input File and Application Data Format
For COMPANY B to use COMPANY A’s data file to feed their application they will first need to map COMPANY A’s XML Child Node names to their Flat File Data Element names. This can be difficult to do without a good understanding what exactly is provided in the XML Child Node names and the Flat File Data Element names.
This would have been a much simpler mapping process if UDEF IDs were associated to both applications and/or data standards. See the same XML file from COMPANY A below with UDEF IDs and look at COMPANY B Flat File Layout with UDEF IDs included below. Even though existing standards can provide this capability, the UDEF simplifies the integration resulting in cost and time savings.
Input File and Application Data Format – UDEF Tagged
Having the UDEF IDs in both shows us which XML Child Notes and Flat File Data Element have the same meaning. We still may have differences in field size and type, and missing or extra data items; but the semantic alignment has been simplified.
COMPANY B only has to do assign UDEF IDs to it’s flat file layout once. Once this is done COMPANY B can use that information to do their semantic data element alignment with any other entity that needs to provide them data. So the more entities that use UDEF the more cost savings we can expect throughout the industry.
The UDEF enables rapid comparison of appropriately tagged XML files to determine how their semantics correspond. This simplifies and speeds up development of interface software. You can use the gap analysis utility to do this. Submit two XML files, each containing UDEF IDs as illustrated by the input sample and the target sample. One should be from a source system and the other from a target system that need to exchange data. A gap-analysis report is generated.
The example illustrated below shows the use of this tool. Figure 5 shows two different file layouts for two different applications used to either generate or process a purchase order. The OAGIS file layout represents the purchase order from a customer’s procurement application, and the xCBL file represents an example target application layout used by a typical supplier’s order management system. UDEF IDs have been embedded within each file. Figure 6 shows a portion of an example gap analysis report generated by the Online Gap Analysis Service in less than 1 second for the source and target files shown above. Within the report a null indicates that the data element from one application does not have a corresponding data element in the other application.
UDEF-Tagged Source and Target Files
Gap Analysis Report