You can improve the time to load published data in 3DWorkbook
as well as decrease the total size of data that can load in 3DWorkbook.
This is accomplished by replacing product structures in the published product with
CGRs.
This provides the following capabilities for these apps:
Work Instructions
Workplan Publication
3DWorkbook
APRISO
The CGRs create in two primary cases:
Merging the data of a single buildup category (for Previous and
Additional Products)
Merging the data of a single granular object (single object that can detail in 3D
Views)
Benefits
Web viewer app at shop floor (3DWorkbookapp,
APRISOapp)
performance improves for the following reasons:
A smaller number of references load from the database.
The total loaded data is smaller because the CGR data is smaller in size than the 3D
Shape data it replaces.
The generated CGR captures the filtering applied at the time of publishing. This
prevents the loading of objects in the web viewer that did not load in session at the time
of publish in Workplan Publicationapp.
In the case of CGRs for buildup categories, 3DWorkbook is
applying buildup properties to a smaller number of objects.
Costs
Using this applies the following costs:
Publish in Workplan Publicationapp takes
longer because of the generation of CGRs.
The CGRs are a duplication of geometric data and takes up database space.
CGR Per Buildup Category
Merging all geometric data for the entire buildup category provides a major performance
improvement. This is because a product structure replaces with a single lightweight rep.
However, the solution can only apply if the following conditions are true:
The content of the category is constant for all operations under the published system:
The set of granular objects
The display products of granular objects
The FTA Requirements display for the granular objects
The content of this does not have any 3D View overloads or associated marker.
Due to these requirements, the only buildup categories that are merged into a CGR are
Previous Out-Of-Scope and Additional
Products.
Note:
Previous Out-Of-Scope is defined as objects of the category Previous
that are not selectable in 3D Views because they do not share a common scope with the
operation being detailed. Below are acceptance tests for examples of Previous
Out-Of-Scope and Previous In-Scope.
Note:
The categories of Current, Previous in
System, Parallel, and Assigned
Resource are not merges because their content changes between operations. The
category of Context does not merge because there is an App Options that can make it pickable in the 3D Views for Work Instructions
authoring in Work Instructionsapp.
Note:
If a Previous Out-Of-Scope Item has different positions for
difference published operation (due, for example, to positions defined on an operation), it
excludes from the Previous Out-Of-Scope merge CGR.
Previous category - Publish of buildup category
Previous, existing behavior.
Previous category - Publish of buildup category
Previous, new behavior.
Additional Products category - Publish of buildup category
Additional Products, new behavior.
CGR Per Granular Object
If a granular object has multiple categories under a system or has details in 3D Views, it
also benefits from the CGR strategy. This is by creating a CGR under its proxy product. To
avoid creating a CGR in cases where it has no benefit, CGRs do not create in the following
cases:
There is a single display product that has zero loaded product children.
The display products load without filtering:
Resulting Product for an Item
Operation Output for an Operation
Resources
The granular object is displaying fastener data.
Publish of individual granular objects, existing behavior.
Publish of individual granular objects, new behavior.
Publish of granular objects with output, existing behavior.
Publish of granular objects with output, new behavior. No change because the Resulting
Product and the Operation output load without filters.