Integration Mechanism for Publish and Retrieve Functions
Publish and Retrieve (P&R)
Engineering processes can be established to flow information through the integrated environment. In such scenarios, information often originates from one design tool, gets published into SPF, and then consumed by another design tool. This practice is called Publish and Retrieve and is typically leveraged to consume data and avoid errors that can occur when manually trying to keep up with changes between the tools. The practice does not eradicate discrepancies between the tools as this is a gated process that depends on users performing both operations (Publish and Retrieve) and accepting any changes that have been identified.
Export and Import (E&I)
Another approach that is used to copy data from one application to another is Export (from the source) and Import (into the target). A number of these interfaces have been developed for the Jansen project, where there is not an OOTB publish/retrieve mechanism in place. The primary difference between P&R and E&I is that E&I does not have a mechanism to determine what has changed in the target application since the last time that data was imported. Therefore there is no ‘to-do list’ mechanism provided to guide the user through the process of accepting or rejecting the changes to the target application database (it is all or nothing exchange).
Data flows for P&R and E&I
The various data flows between the engineering applications, whether they be P&R or E&I have been documented here:
Publish and Compare
Engineering processes can be established to push information to SPF and then compare discrepancies within SPF. These data discrepancies or inconsistencies can be reviewed in the Cat.4 Post-Publish reports. This practice helps only to identify discrepancies (inconsistencies) between the published data so that corrective actions can be taken. It is important to understand that this practice does not compare data as it exists directly in the design tools, but rather as published to SPF. This means that the publish operations must be observed, followed by acting on any corrective actions, and subsequently republishing to clear the inconsistency report.
Note: Cat.4 Post-Publish reports do not operate on the native application databases, therefore data handled by E&I shall not appear in these reports unless the data is subsequently published to SPF. For consistency checking between the native application databases, Cat.4 Pre-Publish reporting has been configured for a small subset of project properties.
Consolidated Data Warehouse (CDW)
The CDW is a rollup of tag and other non-tag data coming from various design tools. In contrast to a comparison of the data, the consolidated data uses rules to define the value that should be considered “actual” for a given object property, in the case that a discrepancy (inconsistency) exists. The current rule is defined as the last to publish is the rolled-up value of the object property. However, where engineering have identified in MDM that the source of a data item should be coming from one particular tool (publish) and should never be overwritten by another tools publish, then a Rule of Precedence (RoP) can be configured to prevent the overwrite.
Combining the Tools
Meeting the project needs often means combining these tools for different use cases. The design tool practices, engineering procedures, and project standards all work together to establish use of these facets to meet the objectives of the project.
