I have been playing with MicroStation CONNECT and studying ProjectWise CONNECT.
While Bentley has changed names and operability of its MicroStation configuration levels (organization, workspaces, worksets, roles), it appears that Bentley has not made any changes to the managed workspace levels (site, project, discipline, etc.) in ProjectWise .
Is Bentley formally defining any parallels between MicroStation CONNECT configuration levels and the ProjectWise CONNECT managed workspace levels? Will the managed workspace levels change names or operability in ProjectWise CONNECT in future releases? Does the MicroStation CONNECT WorkSpaceSetup.cfg file have any impact on ProjectWise managed workspace CSB's? Will MicroStation users experience anything in the interface that says "WorkSpace" or "WorkSet" when working in the ProjectWise CONNECT environment?
As of update 10 or 11 the workspace can be separated from the workset. They must be defined but not longer are required to be in ProjectWise. So we keep the workspaces and the configuration for them on a local server x's offices with a similar mapped drive. The workset configs and dgnws files are stored in PW and are named the same as the PW project. Everything for these items are stored in PW CSB's to allow PW to resolve all paths up front before MicroStation or any Connect application can step in and saturate the environment.
We set the configuration to the workspace level to the server and not in ProjectWise, then the workset is defined to be in ProjectWise. This ensures that the 2 levels of the Connect configuration that is required is in check, Workspace and Workset. You must define and resolve these. Mandatory for the Connect configuration and very different in limitation compared to V8i. Any failure will result in problems, and more so with any application except MicroStation. Programs such as AECOsim/OpenBuildings fail hard if things are not in check. Another important factor is the workset/project is a ProjectWise project. Something in the folder structure must be a ProjectWise project in order to resolve the workset configuration and use the "$(LastDirPiece(DMS_PROJECT(_DGNDIR)))" variable to find that PW project. it should be defined as:
_USTN_WORKSETNAME = $(lastdirpiece(dms_project(_dgndir)))
It is just how Bentley designed it so we must work within the confines of it. Be sure to define a location for the WORKSETSROOT location as this determines where the workset cfg and dgnws are found. We keep these in a single folder in the hope that Bentley relaxes the configuration requirements for this. But we can also run a query on this to validate that the workset cfg exists. The file can be completely empty but it must exist. Same with the workspaces cfg file.
We create the workset config file manually (scripted via PW admin and PowerShell) and when MicroStation CE or any Connect application is started for the first time on the project, the configuration in place validates that the workset config is in place and then natively the Connect application checks to see if the dgnws file is in the same place as the workset.cfg, if Yes, then PW pulls it down and uses it, if No, then the Connect application automatically creates it in the dms folder, pushes it into PW, checks it in and then uses it. I have not found a way to create a dgnws and push it into PW outside of this workflow in a seemless process. Seems like the Connect application needs to do all that work.
Thanks Mark, appreciate your help. Do you know if there are compatibility issues in terms of managed workspaces between the myriad of updates on both ABD CE and PW CE? Why would there be issues in the first place I wonder...
Thanks again
in regards to managed workspaces, MicroStation CE was not fully integrated until update 11 which I believe is update 4 for AECOsim. This is with ProjectWise 3.49, client and server. Those are the minimums.
We just completely redid our CONNECT managed workspace as our old one wasn't working very well. It mostly follows along with the link Phil posted, however we went through lots of rounds of troubleshooting to get the dgnws file to work the way we wanted.
We wanted the dgnws file in the project folder with other dgn files for that project. We did not want a single folder with all dgnws files for all projects in it. Both for security reasons and just easier management reasons.
Documents Office Project CADDLib dgnws
Our typical Projectwise structure is each office using a datasource gets a folder for their office. Under their office folder is a folder for each project they own (this folder is a ProjectWise WorkArea folder). Each project gets a CADDLib folder with a dgnws folder in that. We want the dgnws file to be in that folder. And we want Microstation (or vertical) to create the file in that folder.
What we found was that Microstation is very particular about what level (workspace, worksheet) certain variables are set at. To get it to work with ORD, OBM and MicroStation we did the following:
In the config file for the WORKSPACE we set:
_USTN_WORKSETROOT = DMS_PROJECT (_dgndir) _USTN_WORKSETSTANDARDS = $(_USTN_WORKSETROOT)CADDLib/ # Location of DGNWS files are per workset _USTN_WORKSETSDGNWSROOT = $(_USTN_WORKSETROOT)CADDLib/dgnws/ %lock _USTN_WORKSETSDGNWSROOT
The lock seemed necessary. Note that this configuration is pretty generic in that it doesn't reference the workspace, but if I set this anywhere other than the workspace config file all kinds of weird things would happen.
Then at the WORKSET config we set:
_USTN_WORKSETDGNWS = $(_USTN_WORKSETSTANDARDS)dgnws/$(_USTN_WORKSETNAME).dgnws
Again, putting that at a level other than workset seemed to cause weird behaviors (the weird behaviors were different for ORD and MicroStation. MicroStation was Update 14, I think the current ORD is built on an older Microstation version). Also it may seem a bit redundant to set both the _USTN_WORKSETDGNWSROOT AND _USTN_WORKSETDGNWS variables but we found we needed both set for ORD, OBM and MicroStation to all work.
Finally one last problem we ran into. If we let ORD create the dgnws file, it would create it in the correct location with the correct name but we would be unable to edit the dgnws file. If we let MicroStation Update 14 create the dgnws it worked fine in both MicroStation and ORD (and OBM). Thinking it was a problem with the template files in the older ORD we put the template files from MicroStation Update 14 in our Corporate standards and set:
_USTN_WORKSPACETEMPLATE = $(_HNTB_STANDARDS_ROOT)Template/WorkSpace.Template _USTN_WORKSETTEMPLATE = $(_HNTB_STANDARDS_ROOT)Template/WorkSet.Template _USTN_WORKSETDGNWSTEMPLATE = $(_HNTB_STANDARDS_ROOT)Template/WorkSetTemplate.dgnws
That is set in our Organization config file. I just noticed I left in _HNTB_STANDARDS_ROOT, that's the same as _USTN_ORGANIZATION, we just prefer using our own variable.
This is how we implementing also. Each project has a Workset folder in which a single workset CFG file is placed along with the matching dgnws file. The DGNWS file is automatically created by the CE design application. You must create the appropriately named workset config file in the location defined by _USTN_WORKSETSROOT. The file doesn't have to set anything but must exist in PW.
#----------------------------------
# Set Work set root path to project
_USTN_WORKSETSROOT = $(dms_project (_dgndir))DesignData/CAD_Standards/Worksets/
%lock _USTN_WORKSETSROOT
#-----------------------------------------
# Set Dynamic Workset Name to Project Name
_USTN_WORKSETNAME = $(WS_PROJECT_NAME)
%lock _USTN_WORKSETNAME
If you have issues with the wsdgn file not creating check your local dms folder and make sure you don't have any dgnws files left behind. When testing you end up deleting files but forget to purge first. If the dgnws file already exist in your local cache it will not be created in ProjectWise.
Greg Roberts said:If you have issues with the wsdgn file not creating check your local dms folder and make sure you don't have any dgnws files left behind. When testing you end up deleting files but forget to purge first. If the dgnws file already exist in your local cache it will not be created in ProjectWise.
Omg, I forgot to mention this. IT IS INFURIATING!
Yes it is! I wasted countless time with randomness (worked some times and not others). Something I'll never forget....
Glad to see I'm not the only one :-). Thanks for all the useful details I'm getting from you indirectly :-)