‎29-11-2021 03:10 PM
We have noticed that some features are not available anymore, in a standard installation, due to the change from private workspace to public workspace.
I know we can change the meta-model where we change the WET back to private but, is that the recommended approach if a customer has the needs to manage their changes in collaborative workspaces, design tasks etc.?
‎08-11-2023 10:42 AM
This thread is still very relavant
‎04-02-2022 05:20 AM
‎03-02-2022 11:09 PM
BTW, where in the metamodel can you change it back to private?
Very useful for a dev environment if you're testing automation/import or other macro stuff to be able to discard the changes.
‎25-01-2022 09:34 AM - edited ‎25-01-2022 09:35 AM
Having used in the past Mega/Hopex implementations with several repositories and transfer of objects from one to another, I confirm that it is a robust solution but also add a certain level of administration additional workload and complexity mainly due to the difficulty to transfer complex "High level" objects with multiple children's and links like application for example.
‎25-01-2022 06:36 AM
Hi, Yes this is also an approach, and an approach that was used in the past. But in my experience, it creates an enormeous task of maintaining the artifacts that needs to be transferred. Even with with the ability to move content from one repository to another automatically using Transfers, you still must validate artifacts, make sure they are locked (including all sub-components) - and keep them locked untill the transfer, otherwise the transfer from the design repository to the publishing repository will fail. This means you will now also have to run the Validation workflow on objects to get them locked, or at least build in the locking mechanism in the workflows you use for the different artififacts (which is the methid we prefer). Checking artifacts out in a collaborative workspace simplies this task and is much easier for the users to understand. Keeping everything in one repository makes life so much easier 😀
‎24-01-2022 08:42 PM - edited ‎24-01-2022 08:44 PM
Hello @hsoegaard , @oguimard
Our organization is new to Hopex and we're finding this change "interesting" and are discussing how to adapt. Our pre-sales discussions were done with version 4.
Regarding moving from Scenario 2 to a more governed architecture model - maybe a best practice with HOPEX is to create a "Published" repository along side the "work-in-progress" repository. Then, only those building blocks (artifacts) which have passed governance are moved from the "working copy" repository to the "Published" repository. I realize this probably adds a layer of complexity to a HOPEX deployment and management of the platform.
Just a thought. We seem to be leaning to that model. Important note - we are just starting to adopt HOPEX V5 - so we don't have architects who are used to workspace features in previous versions.
‎03-01-2022 09:56 AM
Hi,
Even if you are in scenario 2, that dosnt mean you can completely abondon Governance. Scenario 1 is also vey much about being in control of your work.Therefore you would still need the Request For Changes with the Design Tasks to track what you have changed.
We also see users starting out with scenario 2 when they start using HOPEX (it is a more simple approach). However, later when their models needs to come under a Governance regime, they need to be able to switch to scenario 1.
As of V5, this can only be accomplished with a change of the meta-model (although it is avery simple change with check mark that needs to be changed).
‎03-01-2022 09:10 AM
Hello,
There are 2 approach to modeling.
The trend that we see is that more and more users prefers to share immediately the work.
Having a "collaborative workspace" make sense in scenario one (1). In that scenario you may want to be several to work on a long time on element before to share them.
In the second scenario (2) , you share everything immediately; so everyone can work with you, there is no need to create a "collaborative workspace".
Because of this new trend, the default behavior in V5 is to promote public workspace. Therefore this feature of collaborative workspace is not available as it doesn't make sense.
You seems to be in the situation were your customer is in scenario one (1). You then don't have a choice than to edit the default configuration.
The same thinking apply for design task.
‎31-12-2021 12:23 AM - edited ‎31-12-2021 12:23 AM
Hi,
Do you have the answers that you needed for the missing features in V5 or still waiting for someone to reply?
Feel free to submit separate Support cases for all your questions. Someone in Support Team will be able to assist you.
Thanks,
Philip