An out of the box installation of a CONNECT Edition application is largely centered on folders in Windows' default ProgramData folder. This has to be done so the application can be successfully installed in a fully functioning state. However, live operational data is in practice almost always located on network shares for security and sharing.
The location of shared network resources in the Custom Configuration is discussed elsewhere, including in other "Custom Configuration" items in this blog.
Our example configurations generally include the WorkSets that contain project design data, e.g. the primary DGN files within the Custom Configuration. Obviously this is not an appropriate arrangement in practice.
In addition to maintain organizational standards it is desirable to separate live project data folders that are accessible to all project staff from the standards resources and configuration files that should be managed by organization or project administrators. For instance, a project CAD Coordinator in the case of project specific resources such as cell or level libraries.
This separation is actually quite simple to achieve in CONNECT Edition.
A set of Bentley WorkSets are contained within the location defined by _USTN_WORKSETSROOT (the plural…), this is always a WorkSpace. Each WorkSet contains everything that relates to it including the two crucial files that can upset the smooth running of a project if they are lost or damaged.
Project resources and design data are stored in the sub-folders of each WorkSet folder. The location of this folder and its contents are defined by _USTN_WORKSETROOT (the singular…).
_USTN_WORKSETROOT can be defined to point to a separate share or drive mapping keeping the live data project user totally separate from organization standards.
Each WorkSet contains its own set of Standards sub-folders so a project team can add or edit project resources, adding project cells for instance without needing additional access/permissions.
It could be defined in each WorkSet.cfg but that could require each WorkSet.cfg file to be edited.
With a consistent naming strategy it could be defined once in each WorkSpace.cfg. This is the most appropriate level.
Note in this screengrab that WorkSet_01 and WorkSet_02 have .CFG, .DGNWS and their data folders all contained within …\WorkSpaces\WorkSpace_01\WorkSets.
WorkSet_03 only has the .CFG and .DGNWS files.
That is because WorkSet_03.cfg contains the line:
_USTN_WORKSETROOT = //server/ProjectData/Project_03/$(_USTN_WORKSETNAME)/
This relocates the data folders to \\server\ProjectData\Project_03\WorkSet_03
Exactly how these data folders are structured and named can be configured, preferably at the WorkSpace level for consistency across projects. In this example the Bentley defaults are used.
Note: default structures could be applied at the organization level but that would be relatively inflexible. Setting them at WorkSpace level makes it easy to:
When _USTN_WORKSETROOT is defined as shown above to separate design data from project resources, the location of each WorkSet's DGNWS file needs to be considered, please read CONNECT Edition - Configuration Tips : Where should I keep my DGNWS files? for more on this. The DGNWS contains valuable data that needs to be looked after.
NOTE: At the time of writing this arrangement was not fully supported by the WorkSet Creation UI. If the WorkSet_03 in the above example is used as a Template WorkSet the WorkSet.cfg is created in the expected location but the WorkSet folders are not. We are investigating this and will update this article once we have new information.
A reliable solution at present is once a working configuration containing WorkSpaces and WorkSets are established, for each new WorkSet manually duplicate an existing WorkSet.cfg and WorkSet folder renaming both to the new WorkSet name.Translated German Wiki article:CONNECT Edition - Benutzerdefinierte Konfiguration - Teil 5: Trennung von Projektdaten und Standards