This custom attribute can be found in the standard schema CoreCustomAttributes and it enables the iModelHub to programmatically detect dynamic schemas. The DynamicSchema custom attribute should be set on customer specific application schemas. This follows the general schema update strategy defined in Schema Versioning and Generations To provide consistency and enable concise change sets, the Bridges add to the previously-defined schemas (creating new schema versions). To avoid losing data, iModel Bridges may dynamically create application-specific schemas whose classes descend from the most appropriate BIS domain classes.Īs iModel Bridges always run multiple times to keep an iModel synchronized, the schemas created by previous executions limit the schemas that can be used by subsequent executions. Sometimes BIS domain schemas are not adequate to capture all the data in the authoring application. However, where clear BIS schema types exist, they should always be used. The appropriate balancing of these two conflicting goals is not an easy task. To transform the data in such a way that data from disparate authoring applications appear consistent.To transform the data in such a way that it appears logical and "correct" to the users of the authoring application.Bridge jobs hold the locks for all of their data, so it may not be modified by other iModel applications.įor each iModel bridge author, there will always be two conflicting goals:.The resulting combined iModel is partitioned at the Subject level of the iModel each Bridge job has its own Subject. Each job generates data in the iModel that is isolated from all other jobs' data.This creates a "back-link" from data in iModels to its source application. Bridges locally store a mapping of native source Ids to iModel global Ids.This is the key difference between a Bridge and a one-time converter. In this manner bridges generate ChangeSets that are sent to iModelHub. If necessary, bridges store enough information about source data to detect the differences in it between job-runs.Mappings of data are from source into an iModel.The application source file and destination iModel are identified in mapping.Ī bridge-job is the combination of connection and mapping and may be run on a pre-determined schedule. All this data is specified in the connected project web-UI under connection. Any desired bridge can be installed on the Automation Server. The Automation Server has access to a ProjectWise managed data source that contains the application native files. The Orchestration Framework is installed on an Automation server machine. IModel Bridges need to carefully transform the source data to BIS-based data in the iModel, and hence each Bridge is written for a specific data source.īridges are invoked by the Bentley Orchestration Framework(OF) product. Many iModel Bridges can be associated with a single iModel and hence the resulting iModel becomes an aggregator of many sources of data. IModel Bridges exist for the purpose of transforming data from these other applications into iModels in iModelHub. Often, information modeled in an iModel is created by an application that stores its data in another format.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |