Data Enrichment – Static and Dynamic Sources Part 2
/The previous blog post focused on the enrichment capabilities of CADnection. The data sources for the enrichment process are either static or dynamic. In this blog, we will explore the implications for treating these two sources.
As a recap of Part 1 (URL), CAD model data is inherently a rich collection of tag/value information that touches a wide range of disciplines such as sourcing, manufacturing, quality, and test specifications. Even with this wealth of data, it is simply a subset of a broader collection of product data and associated processes. For example, a custom-manufactured part will have documented requirements, its bill of materials (BOM), approved supplier(s), pricing schedule, and more. This data is typically scattered about in file folders, product lifecycle management (PLM), enterprise content management (ECM), and enterprise resource planning (ERP) solutions, for example. CADnection’s enrichment process and capabilities allow for this data to be retrieved, merged, and provide users with a unified view of information. However, to ensure accuracy in what is presented, it will be critical to capture changes in a timely manner. Hence, the importance of distinguishing between static and dynamic sources of data.
For static data sources, the synchronization challenge is a minimal concern. A good example is the relationship between the CAD model authoring application and its corresponding file extension. The name of the application names is typically not found in the CAD model. CADnection ships with such a “static” table and provides the option to “turn-on” the relationship between the CAD model file extension and the actual originating application. This application value is then inserted as the enrichment attribute for the application name. The point here is that it is highly unlikely that the file extension would eventually point to a different authoring application. Hence, for static data, there is no requirement for synchronizing changes.
Treating dynamic data sources has implications for two key capabilities:
Provision in the source application to activate a “change in data” flag to CADnection
Upon receipt of the flag, the ability within CADnection to capture that change and update the target application
A critical consideration is the time between the change and its availability in the target application. This metric is referred to as the “change latency period” or CLP. In some regulated environments like FDA, the CLP may be measured in seconds compared to non-regulated environments where it might be found to be acceptable to have a 24-hour CLP.
To support this enrichment process, CADnection leverages an enterprise application integrations (EAI) hub referred to as Nexus - Nexus is a solution published and supported by The vdR Group, Inc. (vdR). We designed Nexus as an alternative to solutions offered by Jitterbit, MuleSoft, Dell Boomi, Informatica, and others. Nexus is a lightweight EAI platform specifically designed for engineering and manufacturing applications and the treatment of parts, bills, documents, and drawings.
With Nexus, CADnection can both retrieve content from various sources of data as well as capture changes activated from the source application. As with other EAI solutions, the primary “hooks” or application program interfaces (APIs), will be vital to the exchange of data.
The retrieval process for both static and dynamic sources is identical. The user specifies the primary key (part numbers for example), target source, and attribute data associated with the key. With Nexus, this data is retrieved and inserted into the CADnection Data Exchange (CDE) file that is ultimately submitted to the target application.
On the source application, a “change in data” function would be added. This can be done in numerous ways, but a typical approach would be to add a change detection process on a post-save action of the item of interest. Upon detecting a change, the process would activate a data submittal operation via Nexus that would pass the attribute tag/value information to CADnection.
In brief, the above “synchronization” process shares the same operating principle as found with “data virtualization” processes.
The next blog in this series addresses the compilation of the CADnection Data Exchange (CDE) file.