Bentley Communities
Bentley Communities
  • Site
  • User
  • Site
  • Search
  • User
ProjectWise
  • Product Communities
ProjectWise
ProjectWise Design Integration Forum Processing DOT .cfg Workspaces into ProjectWise CSB managed Workspaces.
    • Sign In

    • State Not Answered
    • Replies 3 replies
    • Subscribers 61 subscribers
    • Views 921 views
    • Users 0 members are here
    • Workspaces
    • ProjectWise
    • CSB

    Processing DOT .cfg Workspaces into ProjectWise CSB managed Workspaces.

    Ronald Koons
    Offline Ronald Koons over 1 year ago

    I am looking for other user / developer insight into a sort of "Best Practice" when it comes to adapting DOT Workstation / Server WorkSpaces into ProjectWise CSB based Managed Workspaces.

    I'm sure there must be something out there in the digital ether detailing an answer to this simple question. Or, possibly it’s all a matter of opinion and project specific needs and requirements.

    My thoughts specific to this discussion are simple:

    Like most of us, I am starting from a collection of standard Bentley .cfg files, designed to execute starting with the running of a program on a workstation to open a file on a server, triggering local and server based .cfg files, all probably accessing server based common resources.

    I have to take these and make them all work properly in a ProjectWise CSB Managed WorkSpace. Usually, I need to keep it as simple as possible AND, complete the conversion as quickly as possible.

    As I see it, there are basically three camps of thinking:

    1. Convert every single variable into either a ProjectWise folder or document assignment in ProjectWise Administrator using Managed WorkSpaces.
    2. Convert only those major variables that are the basis for all other variables into ProjectWise folder assignments, leaving most others as variables that now depend upon these main variables being assigned to a specific folder in ProjectWise. These variables would be in a CSB, NOT kept as a .cfg.
    3. Use Dynamic Managed Workspaces (Which is simply a more complex version of the second option above).

    Reviewing what I could find online, I can see no real official discussion on what is a best practice. In fact, with the development and advancement of Dynamic Managed Workspaces, it seems that a more mixed bag of CSB and .cfg files is becoming the norm.

    My basic thoughts are:

    Many persons I work for and with are of the first camp: convert every line into a ProjectWise directed folder or document assignment. The thinking, I believe, is that this takes full advantage of the flexibility and adaptability of the CSB system in ProjectWise.

    My thinking is that if I follow the second option above, it allows me to make sure the main variables are assigned and managed completely by the CSB system in ProjectWise, AND, makes the bulk of the conversion of the DOT WorkSpace much quicker by simply importing the .cfg files and then doing a little cleanup. By following this, the process of setting it up is quicker. Making changes is also quicker as the original intent of most of the variables are preserved.

    To me, doing the first option adds an additional layer of complexity in the conversion process that makes setup and troubleshooting that much harder.

    My shortcoming in this is:

    I am told that the second option eliminates the advantage and the “Power” of the CSB system. If this is true, based upon how I am trying to set this up in option two, I don’t understand why.

    Finally, and in all fairness to those persons I work with and for who might read this: I am not apposed to whatever way my company wants it done. I just prefer to understand the “whys” of it all better than just “It’s always been done that way”.

    Thanks to all for your thoughts!!

    • Sign in to reply
    • Cancel
    • Kevin van Haaren
      0 Offline Kevin van Haaren Wed, Jul 27 2022 4:15 PM

      I'm not sure how much editing of variables you've done in CSB blocks, but I find creating/editing CSB variables to be completely aggravating, it would take me days longer to manually create all the variables we need (OpenRoads Designer is bad, but OpenBridge Modeler is even worse in terms of the number of variables).

      I'm just going to deal with Connect based products, I've done similar for V8i but the implementation details are different.

      One thing to remember is that with Connect even if you opt for the all CSB route the Connect products will attempt to load .cfg files from certain folders, even if the folders are in projectwise, and if you happen to have those cfg files in those folders they will be loaded. My implementation is for OpenRoads Designer, OpenBridge Modeler and OpenRail Designer. I assume the other Bentley verticals are approximately the same.

      I leverage the auto-loading of cfg files as a plus. I define 2 folders as actual projectwise folders in CSBs all others are built off these 2 variables (I do define some other directory variables in CSB but they use 1 of the 2 variables as it's ultimate base folder).

      CSB:
      Pre-Defined Level
          Define _PW_CONFIG_ROOT as projectwise folder (with a string appended)
          Define _USTN_CONFIGURATION $(_PW_CONFIG_ROOT)_Configuration/
      Customer Level (one csb per client)
          CSB: Defines location of our client standards, _CLIENT_CONFIG_ROOT = $(_PW_CONFIG_ROOT)Clients/ClientName/
               CSB %include $(_CLIENT_CONFIG_ROOT)CLIENTNAME.cfg
      WorkSpace Level (each of our office locations is their own workspace, one CSB per workspace)
          CSB: Defines _USTN_WORKSPACENAME
      WorkSet Level
          CSB: Defines _USTN_WORKSETNAME as lastdirpiece (DMS_PROJECT (_dgndir))
      

      Now using Connect's auto-load config, with the settings above what happens is:

      _USTN_CONFIGURATION causes WorkSpaceSetup.cfg to load. In this cfg file I define most of the standard folders:

      • _USTN_ORGANIZATION = $(_PW_CONFIG_ROOT)Organization/
      • _USTN_WORKSPACESROOT = $(_PW_CONFIG_ROOT)WorkSpaces/
      • _USTN_WORKSPACEROOT = $(_USTN_WORKSPACESROOT)$(_USTN_WORKSPACENAME)/
      • _USTN_WORKSETSROOT = $(_USTN_WORKSPACEROOT)WorkSets/
      • _USTN_WORKSETROOT = $(_USTN_WORKSETSROOT)$(_USTN_WORKSETNAME)/

      Setting _USTN_ORGANIZATION causes all cfg files to be loaded from this folder. I set our corporate standards here, always using $(_USTN_ORGANIZATION) for paths. _USTN_ORGANIZATION uses the _PW_CONFIG_ROOT projectwise folder.

      The customer level csb will manually load a cfg file from our clients\clientname folder. about 80% of our client configs use Bentleys Organization-Civil folder structure, when they do this I can just modify their base variable to point to our client folder and make no other changes to their config file, just copy it into the proper location and name it properly.

      Setting _USTN_WORKSPACESROOT and _USTN_WORKSPACENAME will load the workspace cfg automatically

      Setting _USTN_WORKSETSROOT and _USTN_WORKSETNAME will load the workset cfg file automatically.

      With this setup I put 4 CSBs in place on a project, 2 of which are always the same (predefined and project), and 2 that i only need to create when we get a new office or new client (client and workspace).

      On my note that our my base folder is a projectwise folder with a string appended, this is so I can work around ProjectWise's issue with not deleting files off the local system when they are deleted from ProjectWise.

      When you define a ProjectWise folder or ProjectWise file, Projctwise stores the GUID of that folder/file in the CSB. If you delete that folder or file, even if you replace it with a folder/file of the same name the GUID has changed and the resource won't be found or won't load.

      If you define something with a string, ProjectWise won't resolve this to a GUID until it processes the CSB (or cfg file) at launch time. This means if you deleted a folder or file and replaced them with something of the same name, the new GUID will be resolved the next Microstation launches.

      In addition, if you have a variable that loads all files in a folder:

      MS_DGNLIBLIST = path/to/folder/*.dgnlib

      If you delete one of the dgnlib files on the server, any user that had a copy of that dgnlib locally will continue to use that dgnlib because *.dgnlib says to.

      My fix for this is since all my paths are built using a projectwise folder with a string appended, i can delete a whole folder, replace all the files in it and users will re-download the new folder and files and will never load the old file. Downside is all the files in that old folder are now orphaned.

      So say i wanted to delete a dgnlib, i would:

      • rename existing path/to/folder to path/to/folder-old
      • create new path/to/folder
      • Copy just the files i want to keep from folder-old to the new folder

      Next time the user opens Microstation, the newly created /path/to/folder is copied locally and only dgnlibs in that folder are used. The deleted dgnlib is no longer used.

      One other cute trick, say path/to/folder had some sub-folders like levels, gui, etc..

      • /path/to/folder
        • GUI
        • Levels

      Now when I replace /path/to/folder if i MOVE (not copy!) the sub-folders to the new /path/to/folder then user's will NOT re-download those folders. When you do a move the GUID of the folder remains the same so ProjectWise will see them as the same folders the user has already copied out.

       

      • Cancel
      • Vote Up 0 Vote Down
      • Sign in to reply
      • Verify Answer
      • Cancel
    • Ronald Koons
      0 Offline Ronald Koons Thu, Jul 28 2022 5:31 PM in reply to Kevin van Haaren

      Wow... So much interesting information; I'm glad I called this a conversation and not a question.

      So, let me first respond with my questions / comments on your post and setup:

      “I'm not sure how much editing of variables you've done in CSB blocks, but I find creating/editing CSB variables to be completely aggravating, it would take me days longer to manually create all the variables we need (OpenRoads Designer is bad, but OpenBridge Modeler is even worse in terms of the number of variables).”

       

      I agree. However, in my case, the directive that the company follows is a bit different.

      Typically, someone takes the original .cfg files from the DOT workspace, and creates usually one large CSB under “Managed/WorkSpace”. These files would include ONLY ProjectWise file and/or folder assignments, using no real variables at all.

      I come form a long background of Server / Workstation based Workspace setup, so I am used to the .cfg approach to things. However, based upon the above preferred method, combined with my background and “personal preferences, I take your approach a little differently:

      Using your example, I will take what I consider critical variables:

      _USTN_CONFIGURATION

      CIVIL_ORGANIZATION_ROOT

      _USTN_WORKSPACESTANDARDS

      CIVIL_ORGANIZATION_STANDARDS

      And put them in CSB files using only ProjectWise Folder Assignments. This is done basically by importing the original .cfg files with the import tool in ProjectWise Administrator. Once completed, it allows me to have a collection of CSB’s that mimic the original .cfg files. Additionally, once I convert those major variables noted above, each in the files they originally came in, the rest of them all fall into line and work properly based upon the WorkSpace folder we use to set all the resources into.

      This is NOT how our company prefers it to be done, but so far, it seems to do the trick, allowing me to use CSB’s as preferred and still maintain the original DOT intention.

       

      “Setting _USTN_WORKSPACESROOT and _USTN_WORKSPACENAME will load the workspace cfg automatically

      Setting _USTN_WORKSETSROOT and _USTN_WORKSETNAME will load the workset cfg file automatically.”

       

       

      One Question I have is:

      You say using variables and .cfg files, this will not only load the .cfg files, but set the proper ProjectWise location for these variables.

      What I am finding is that, If I try to set specific variables like these in a CSB -even if the syntax is correct, it will usually only default to the “C” drive location..?

      Is this another wonderful ProjectWise Bug?

      “CSB:

      Pre-Defined Level

          Define _PW_CONFIG_ROOT as projectwise folder (with a string appended)

          Define _USTN_CONFIGURATION $(_PW_CONFIG_ROOT)_Configuration/”

       

      So… It looks like everything is built from _PW_CONFIG_ROOT, using variables in the CSB. How exactly is the initial variable _PW_CONFIG_ROOT set?

       

      “WorkSpace Level (each of our office locations is their own workspace, one CSB per workspace)

          CSB: Defines _USTN_WORKSPACENAME

      WorkSet Level

          CSB: Defines _USTN_WORKSETNAME as lastdirpiece (DMS_PROJECT (_dgndir))”

      These two variables are two more examples of variables I can’t seem to ever get to set properly in a CSB using non-cfg. Options like you do.

      In other words: If I simply add a line in a CSB saying:

      _USTN_WORKSPACENAME = $( CIVIL_ORGANIZATION_ROOT)ClientName\ConfigName\

      For example, it will default to “C” every time.

       

      “On my note that our my base folder is a projectwise folder with a string appended, this is so I can work around ProjectWise's issue with not deleting files off the local system when they are deleted from ProjectWise.”

       

      If I am understanding this right, I believe we are having this same problem using ProjectWise Drive in conjunction with Dynamic Workspaces. My local copies on the “C” drive cache for ProjectWise drive does download and synchronize files as expected, but If I add a file for example it will not synchronize the new file up to ProjectWise: I have to do it manually and then select the proper application to open it.

       

      “So say i wanted to delete a dgnlib, i would:

      • rename existing path/to/folder to path/to/folder-old
      • create new path/to/folder
      • Copy just the files i want to keep from folder-old to the new folder”

      Am I correct in assuming that if I delete the files in the target and then just replace them with the new collection of files in the same folder name, the system will then replace the old files with the new ones (with the same names), and then add the new ones (New files)?

      The only other thought I still ponder is:  When one says "using the full power and flexability of the CSB system", I know it has it's advantages, but is there a prefered method or a list of Do's and Dont's. Granted, I can see from all of the above and my own personal exprerence in my present postion that there are as many ways to do this as there are admins trying to manage it all. I guess I just never want to miss one of those "Well, if you did it this way, you could..." and then miss something amaizing that Bentley never bothered to tell us about.



      Ron Koons
      EXP | BIM Manager
      Chicago, IL
      USA

      • Cancel
      • Vote Up 0 Vote Down
      • Sign in to reply
      • Verify Answer
      • Cancel
    • Kevin van Haaren
      0 Offline Kevin van Haaren Sat, Jul 30 2022 3:49 PM in reply to Ronald Koons

      One Question I have is:

      You say using variables and .cfg files, this will not only load the .cfg files, but set the proper ProjectWise location for these variables.

      What I am finding is that, If I try to set specific variables like these in a CSB -even if the syntax is correct, it will usually only default to the “C” drive location..?

      Is this another wonderful ProjectWise Bug?

      Hmmm, this depends it may actually be correct. Let's say I set the _USTN_ORGANIZATION variable to a folder in ProjectWise (doesn't matter if it's in a cfg file or via CSB):

      _USTN_ORGANIZATION = pw://intsrv:dsource/Documents/Configuration/Organization/

      When ProjectWise processes the workspace it will convert that projectwise folder into the local working directory path so it'll convert it to the dms##### folder on your local hard drive. This behavior is correct. If you open the Configuration Variables dialog in ORD, that shows the ProjectWise path, but if you do the key-in Show Configuration, the file it opens will show the working directory path (if you see a path with a projectwise URL when using Show Configuration it means projectwise couldn't find that path in Projectwise).

      If your seeing some C: drive path that isn't your working directory then there maybe something else going on. One thing I've found it prudent to do is lock all the key variables when I set them in CSBs. So your list of _USTN_CONFIGURATION, CIVIL_ORGANIZATION_ROOT, etc... I lock all of them when I set them.

      So… It looks like everything is built from _PW_CONFIG_ROOT, using variables in the CSB. How exactly is the initial variable _PW_CONFIG_ROOT set?

      I set in a Pre-Defined CSB. This is the CSB:

      This is the variable definition dialog:

      I set a ProjectWise folder to the folder above the one where my configuration will be, then append a string for the final folder name. Then lock it.

      These two variables are two more examples of variables I can’t seem to ever get to set properly in a CSB using non-cfg. Options like you do.

      In other words: If I simply add a line in a CSB saying:

      _USTN_WORKSPACENAME = $( CIVIL_ORGANIZATION_ROOT)ClientName\ConfigName\

      For example, it will default to “C” every time.

      Not sure if this is a typo, but _USTN_WORKSPACENAME and _USTN_WORKSETNAME should never be complete paths, they should only be names. If you mean _USTN_WORKSPACEROOT and _USTN_WORKSETROOT then as I mentioned above, depending on what the location on your c: it's setting them to it could be correct. If it's some other weird path than something else is going on.

      CONNECT configurations are great at making assumptions it won't tell you about, so if you're seeing the wrong paths, this may be why:

      _USTN_WORKSPACEROOT is the root folder of A single workspace (note WORKSPACE is singular here). _USTN_WORKSPACESROOT is the root folder of where all your workspaces are at (note plural WORKSPACES). Connect uses all these variables to build paths. The default way these are built are:

      • _USTN_WORKSPACESROOT  : $(_USTN_CONFIGURATION)WorkSpaces/
      • _USTN_WORKSPACEROOT     :$(_USTN_WORKSPACESROOT)$(_USTN_WORKSPACENAME)/

      So, if your example is correct for what you're setting _USTN_WORKSPACENAME to, then it will get _USTN_WORKSPACESROOT prepended to it. If that is something weird then your actual workspaceroot will also be weird. This is all repeated with _USTN_WORKSETSROOT (plural WORKSETS), _USTN_WORKSETROOT (singlualr) and _USTN_WORKSETNAME.

      If your configuration is following the standard Bentley folder structure, then setting just _USTN_CONFIGURATION and _USTN_WORKSPACENAME (but only to a name, no path) then everything should work.

      One thing: I probably wouldn't put my workspaces in the middle of the _CIVIL_ORGANIZATION_ROOT. This may cause some very weird behaviors. Instead I'd go with the expected default paths of having a Workspaces folder separate from CIVIL_ORGANIZATION_ROOT, and in that folder a Workspace cfg file named for your client name. Inside that do a %include of the correct _CIVIL_ORGANIZATION_ROOT/CLientName configuration. This follows what ORD kind of expects and I've found it works significantly better to follow Bentley's assumptions here. You can beat it into submission to do something else, but it's a heck of a lot of work.

      Am I correct in assuming that if I delete the files in the target and then just replace them with the new collection of files in the same folder name, the system will then replace the old files with the new ones (with the same names), and then add the new ones (New files)?

      I'm going to ignore ProjectWise Drive because it operates differently, but if your variable is defined as a ProjectWise folder and you always replace all files deleted with files of the same name, then add new files, on the working directory the files named the same will be replaced and new files added will be downloaded. (Note that if you point a variable at a ProjectWise File, then delete and replace that one file with one named the same it does not work)

      Examples:

      On ProjectWise:
      Documents\CADDLib\Organization\DGNLib\
          - fileA.dgnlib
          - fileB.dgnlib
          - filec.dgnlib
      
      In working directory:
      c:\pw\dsource\username\dms00001
          - fileA.dgnlib
          - fileB.dgnlib
          - fileC.dgnlib
      
      You delete FILES only: fileA, fileB and fileC
      Then add new: fileA, fileB, and fileC, plus fileD
      fileA, fileB and fileC will be replaced in the working directory and fileD will be added.
      
      If, however, you delete files: fileA, fileB & fileC
      And only replace fileA and put in a new fileD:
      Documents\CADDLib\Organization\DGNLib\
          - fileA.dgnlib
          - fileD.dgnlib
      
      But the working directory will look like:
      
      c:\pw\dsource\username\dms00001
          - fileA.dgnlib
          - fileB.dgnlib
          - fileC.dgnlib
          - fileD.dgnlib
      and all 4 dgnlibs will be loaded.
      
      Using my method of using strings for the variables, and deleting the DGNLib folder
      then replacing it with a folder of the same name, the local folder will change it's
      dms folder # and only contain correct files:
      c:\pw\dsource\username\dms00002
          - fileA.dgnlib
          - fileD.dgnlib
      
      

      When one says "using the full power and flexability of the CSB system", I know it has it's advantages, but is there a prefered method or a list of Do's and Dont's

      I'm not the person to provide a list of Do's and Dont's when using only the CSB as your configuration. Basically my list is one word for this approach: Don't! Since building our ORD managed workspace approach, starting in late 2019, I've completely thrown out my first 2 attempts before adopting my current approach. My very first attempt was to do everything in CSBs, mostly by importing a cfg file I wrote.

      Here are my biggest arguments against doing everything in CSBs:

      1. Importing variables from a cfg file:
        1. This is OK, but it is wonky and the import tool (last time I tried it) really wants to import an entire workspace, not single files. You can get it to do a single file, but it whines a lot.
        2. Your managing a cfg file and a csb now. Why not manage just the cfg file and not worry about the csb part?
      2. Changing/adding variables:
        1. I guess you could do this by editing your cfg and then importing again, but again you're managing both a cfg and csb now.
        2. Adding a variable is this process (assuming you've already opened PW Administrator and gone to the workspaces section):
          1. double-click CSB
          2. Click Configuration tab
            1. (if the i need to view a wider screen add clicking the open in window button)
          3. Double-click variable
          4. Double-click the value
          5. Edit value
          6. Click OK
          7. CLick OK
          8. Click OK
        3. Here's the process for editing a cfg file, assuming PW Explorer is open and I'm at the folder the cfg file is in:
          1. Double-click file to open editor
          2. Ctrl-F to find variable
          3. change variable
          4. Ctrl-S to save
          5. Close editor
          6. Click OK to check-in cfg file
        4. You'll note that if you have to modify 2 variables in CSB you have to repeat steps C-G each time, while in the cfg file I just keep searching and changing.
      3. Cfg files are actually BETTER for admin control because you get a much finer grain set of permission.
        1. To have someone not a PW Admin modify a CSB you need to install ProjectWise administrator for them, give them granular admin access, and then they can modify whatever CSBs they want.
        2. With Cfg files, set the file permissions on just the specific areas you want someone to be able to change. You could give one set of people permissions to change ClientA's config only, and a completely different set of people to change ClientB's.
          1. This doesn't mean you have to do it this way, currently our cfg files are locked down so only admins can change them, but if in the future we find this is insufficient it's much easier to change the file permissions as needed.
      4. With cfg files you aren't stuck with one comment line per variable. you can put in paragraphs of comments explaining what is going on.
      5. With a good text editor you can leverage things like Syntax Highlighting to minimize mistakes from misspellings or missing one parenthesis.

      You mentioned ProjectWise Drive, and MicroStation Update 17 adds support for ProjectWise Drive configurations. I've not tried these but I'm pretty sure that mixing managed workspaces and ProjectWise Drive configurations is going to be problematic. Managed workspace variables won't translate a projectwise path (pw://) into a projectwise drive path, you have to make sure you're setting them properly in your config for what you want.

      Currently I'm finding ProjectWise Drive not quite ready for day-to-day configuration usage. Mostly because it seems unreliable in copying down updates or (as you noted) uploading changes. I'm also not sure what happens if a configuration resource file like a dgnlib or rsc font gets deleted in the middle of your ORD session.

      However, I suspect ProjectWise Drive configurations are going to be the norm in the future. With my setup where I base everything off a single variable pointing to a ProjectWise location I can just change that single variable to now point at ProjectWise Drive (probably not with a CSB but some other method) and the same cfgs that work for my managed workspaces will work for my ProjectWise Drive workspaces.

       

      • Cancel
      • Vote Up 0 Vote Down
      • Sign in to reply
      • Verify Answer
      • Cancel

    Communities
    • Home
    • Getting Started
    • Community Central
    • Products
    • Support
    • Secure File Upload
    • Feedback
    Support and Services
    • Home
    • Product Support
    • Downloads
    • Subscription Services Portal
    Training and Learning
    • Home
    • About Bentley Institute
    • My Learning History
    • Reference Books
    Social Media
    •    LinkedIn
    •    Facebook
    •    Twitter
    •    YouTube
    •    RSS Feed
    •    Email

    © 2023 Bentley Systems, Incorporated  |  Contact Us  |  Privacy |  Terms of Use  |  Cookies