Why are WorkSpace and WorkSet a Compulsory Requirement?

A follow on from:

https://communities.bentley.com/products/building/building_analysis___design/f/aecosim-speedikon-forum/194081/obd-u6---catalog-editor-vs-config-dialog

and I've had no answer in:

https://communities.bentley.com/products/administration/f/product-administration-forum/195504/product-divergence

Can someone tell me WHY I MUST have catalog data in a WorkSpace and WorkSet.

If I'm setting up an Organisation build these location are irrelevant, but without them I can't run the application. 

  • Hi Sean,

    I understand that a discussion regarding this is ongoing under SR 7001054217. We will get back to you via the SR as early as possible.

    Regadrs
    Aditya

  • Hi Sean,

    Please note that I have included background information in the following, that I’m sure you are fully familiar with, to inform other readers of the context of this discussion.

    In V8i AECOsim had three levels, plus an option to configure a company level where dataset content could be stored.

    This is functionality that was widely requested by Bentley users to enable the use of varying resources for different clients, disciplines, role, etc.

    CONNECT Edition has similar levels, based on the platform configuration found in MicroStation.

    CONNECT Edition configuration is designed to give users of all MicroStation based products the ability to store customised data for their projects at Organization, WorkSpace (aka, group, department, etc; by the way, WorkSpace can be relabelled to match these group descriptions) or WorkSet (aka Project) levels. AS in V8i, the WorkSet receives the accumulated content of all three levels. Populating all three levels is not mandatory (obviously), but their existence is built into the product configuration and both used and supported by code within the products.

    V8i customisation could require quite convoluted configuration to achieve the desired results. We have learnt from earlier experiences and designed CONNECT Edition configuration to have a clear demarcation between system CFG files ‘owned’ by Bentley located with the application in C:/Progam Files and the customisable CFG files ‘owned’ by the user located in C:/ProgramData. This helps to make redirecting to the network and using these levels easier and clearer than V8i. Having said that we are continuing to work on configuration design to make further improvements in response to feedback.

    MicroStation includes No WorkSpace, No WorkSet as a failover option, but this is not intended for production use and can lead to errors. I’ve looked into its use previously and found significant configuration changes would be needed to get everything in its right place. The only suggestion we for people who were adamant that they did not want to use WorkSets was to use a single WorkSpace and WorkSet then lock the WorkSpace and WorkSet options with: MS_CONFIGURATIONOPTS = DisallowSelectingWorkSpace, DisallowSelectingWorkSet.

    Products built on the MicroStation platform, OpenBuildings, OpenRoads, etc., have additional requirements beyond those of MicroStation for dataset content that make use of the configuration levels. OpenBuildings, like AECOsim V8i puts a lot of project specific configuration in the WorkSet CFG (PCF in V8i). In very regularised systems much of this can be set at a higher level, so it may be possible to work back through the configuration variable structure to find the roots of those variables that you wish to control externally via scripting.

    However, some resources must be unique to each project. In the case of OpenBuildings we have tools such as the Floor and Grid Systems managers that store information per WorkSet in the BB_FloorMaster.dgnlib; found in our example configurations in C:\ProgramData\Bentley\OpenBuildings CONNECT Edition\Configuration\WorkSpaces\Building_Examples\worksets\BuildingTemplate_xx\Standards\DgnLib. If you do not intend to take advantage of these tools that may not be a significant obstacle.

    Thinking about your specific case and triggers that might halt the application:  Dataset tools such as the Catalog Editor and Family/Part Editor are designed to operate with three levels to store custom content. This is to meet the requirements from our users that want to deliver read-only content at organisation level, to have the ability to deliver read-only group wide resources at the WorkSpace level and user editable project resources at the WorkSet level. The user interfaces of these utilities contain options to select the appropriate level to store new content, these are the kind of features that may possibly encounter error states if WorkSpace and/or WorkSet levels are not present. (The applications are designed and tested to work with these configuration levels, we do not test without them so cannot verify this observation.)

    Marc

  • 'MicroStation includes No WorkSpace, No WorkSet as a failover option, but this is not intended for production use and can lead to errors.'

    That's news to me.

    'However, some resources must be unique to each project. In the case of OpenBuildings we have tools such as the Floor and Grid Systems managers that store information per WorkSet in the BB_FloorMaster.dgnlib; found in our example configurations in C:\ProgramData\Bentley\OpenBuildings CONNECT Edition\Configuration\WorkSpaces\Building_Examples\worksets\BuildingTemplate_xx\Standards\DgnLib. If you do not intend to take advantage of these tools that may not be a significant obstacle.'

    We don't use it, but we can work around it, not an issue.

    'Thinking about your specific case and triggers that might halt the application:  Dataset tools such as the Catalog Editor and Family/Part Editor are designed to operate with three levels to store custom content.'

    Family and Part editor doesn't give me any issues. At the moment, this is all around the Catalog Editor. 

    'This is to meet the requirements from our users that want to deliver read-only content at organisation level, to have the ability to deliver read-only group wide resources at the WorkSpace level and user editable project resources at the WorkSet level. '

    I don't have an issue with what you say here, but to me that's not what is being done and it's not going to suit everyone. If I have an Organisation build, then I don't want additions at the WorkSpace or WorkSet level automatically. In fact, in most cases we don't have any changes other than we have different project directories.

    'The only suggestion we for people who were adamant that they did not want to use WorkSets was to use a single WorkSpace and WorkSet then lock the WorkSpace and WorkSet options with: MS_CONFIGURATIONOPTS = DisallowSelectingWorkSpace, DisallowSelectingWorkSet.'

    Not ideal, but I'll have a play with it.



  • I agree with Bear - I was not aware that the No WorkSet option could cause problems.

    I have just used this in 3 new builds that I have created to cover 3 different clients within our office.

    I find the WorkSet option in it's current incarnation to be a pain.

    I can see how the WorkPlace WorkSet format could be very powerful, but in its current incarnation it is the opposite.

    All of my builds are working, but that's because I put almost nothing into the Organisation level.

    Instead I use multiple WorkSpaces for different client builds.

    This allows me to have one base build and I can add as many clients as I need as WorkSpaces.

    I think some of the problems we have with the current CE build are because we use the programs for Mining, not multi-storey buildings.

    Also we are Engineering Consultants which means we are required to hold multiple client CAD builds in our office.

    The setup requirements are entirely different for the two scenarios.

    I have two clients (very very large mining companies) who steadfastly refuse (or so it seems) to move to the Connect versions of anything

    despite Bentley dropping support for V8i.

    This creates problems in our office because we have to keep builds for different versions of Microstation and AECOSim/OpenBuildings.

    Generally we are caught between a rock and a hard place because we all started using Bentley Structural, then Bentley changed the program to AECOSim to compete with Autodesk Revit.

    Now we are forced to use a program that is increasingly moving away from its original intended purpose as a structural package and more

    into the realm of Architecture. (please don't tell us to use Autoplant or Prosteel)

    I'm having this rant because I'm writing a new build in AECOSim v6 for one of our clients, and I've just lost the Catalog Editor.

    It's been working OK for weeks, until yesterday I tried the Electrical configuration and now the Catalog Editor won't launch in the Structural package.

    I'm getting very frustrated with Bentley.