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?
We have gotten managed workspaces to function properly with the loading of the dgnws all in ProjectWise. To do this, we have stood up a CONNECT ProjectWise server to support fully managed workspaces, PWDI 3.49 and MicroStation CE U10. The workset.cfg currently is stored at the root of our active projects/worksets folder and the dgnws is located in the project. We have not taken a second look at relocation if the workset.cfg but at the time we were unable to load it from a different location. The dgnws however has to be created locally and then imported into ProjectWise as it is not branding it to the project when it is created. Bentley has not resolved this issue that I am aware of.
Setting everything up on our end so far has been quite the challenge as well as a loss of flexibility compared to V8i. But we do have it up and running with the Client workspaces located on the server at the Organization level, and the workset/project loading from inside of ProjectWise. We have bypassed the Workspaces level since it required a much more stringent workspace environment and folder structure. Greg, Bentley sent us an unofficial document on setting up managed configurations with only worksets in ProjectWise. It allowed us to maintain most of our flexibility and folder structure.
Currently, we have V8i tools and MicroStation CE, AECOsim CE and OpenRoads Designer CE up and running in a managed structure in ProjectWise.
We are running into the same issue now at our organization. Is there any official or "unofficial" documentation on how to setup CE projects with worksets to work with ProjectWise?
OpenBridge Modeler - 10.10.00.85Microstation - 10.16.02.34
Comprehensive 3 Day OpenBridge Modeler Training
Here is the O\official configuration setup guide: https://docs.bentley.com/LiveContent/web/ProjectWise%20Managed%20Configuration%20Setup%20Guide-v1/en/GUID-94B9DA14-6B62-44E0-8778-716B16838208.html
Be sure to read the Limitations section under Before you Begin. You MUST have your Workspace and Workset cfg files in ProjectWise. We create a Workset folder under each project to store the matching workset cfg file and the .wsdgn file. The workset cfg file name should match the Project name assigned in PW as outlined in that document. The workset file in PW doesn't have set any configs if you're using a CSB to set things. The file just has to exist for things to work. We keep our workspace cfg files outside of the project folder structure in a normal folder and that works fine. Just depends on how you're organizing things.
Hello Mark, its 2 years I know but just on the off chance - could you please elaborate on dgnws created locally and then imported in PW... I've done all that with ABD update 3 vs PW 280 and still no joy...
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...
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.
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/
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/
# Set Dynamic Workset Name to Project Name
_USTN_WORKSETNAME = $(WS_PROJECT_NAME)
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.