OMW - Managing User Created Versions

[kjjdelist]

My users have the ability to create their own versions of objects. They know that if they don't check them in when they create them, they will be lost during a full-package build/deploy, so they do a pretty good job of that. We've recently upgraded from B7332 to ERP8 and now have OMW.

If a user creates/mods a version, a new project is created named as their UserID and has them as the PVC administrator. I'm told by our consulting group that the check-in process places the version in DV and into the environment the user is logged in to when the version is made (usually PD). This leaves PY w/o the new/modded version.

What's the generally accepted practice here? Is there a way to make JDE a default PVC administrator for all projects? If so, that would make the promotion of these projects from 21 to 26 easier. Is promoting the project the only/best way to get these user modded objects to PY?

What if multiple users have modified the same version? How do you know which one to promote to keep the most recent one?

 

[SULLY1]

The Object Management Configuration - Activity Rules determime how this works. You can set it up any way you like.

Patty

 

[morglum666]

Re: Multiple environments.

Force all developers to use separate development accounts that only have access to DV9. This resolves that issue.

 

[Zoltan_Gyimesi]

Hi kjjdelist,

OMW is a great tool to manage real Object Librarian type objects, but made a chaotic situation handling Batch Versions (UBEVER), because UBEVER is an other kind of animal than real Object Librarian type objects.

Yes, you can configure OMW very flexible way.

IMHO, not too good practice to grant the PVC Admin "joker" role to the user in her/his Default Project - Supervisor or Developer is enough.

In OMW Config, under Activity Rules, you can change UBEVER Check-In action under 21-21 node from "Local to DV" to "Local to Local". This prevents to Check-In UBEVER to DV Path Code too, when the user signed on other path code.

You can manually add JDE to everybody's Default project (I suppose, you can do it from SQL or from a custom APPL/UBE too).

You can move Checked-In Versions on a regular basis from the Default Projects to a separate project and you can promote this project to PY and PD (of course, you can make your own custom UBE/APPL to do this instead of using OMW manually).

UBEVER can cause many conflicts, problems since OL replaced with OMW.

Regards,

Zoltán

 

[karryd]

We allow our users to create and check in their own versions as well. We use the following process to manage the promotions within OMW:

1. A user creates and checks in his/her own UBE version in PD. OMW puts a copy into DV when it is checked in.
2. If the user wants this version to be maintained, they have to submit a request to our help desk and one of our report writers reviews the version and checks for naming convention and if the version is required. Sometimes our users get lazy and create new versions when there are existing versions that would fit their needs already created.
3. The report writer moves the object to one of his/her own projects and promotes the version to PY and documents what it is and does, etc.
4. A custom report is run before each production package build that shows all of the objects promoted or checked into Production. This helps us keep track of new versions and who is creating them.

This is basically how we manage it. We did not change OMW to handle this becasue we do not have too many requests to manage (yet).

This may not be the solution for you, but I hope it helps. Our users and report writers had some challenges with OMW when we moved from B7332 to ERP8 a few years ago.

KD.

 

[jean_driscoll]

We have a group of Super Users who maintain the versions for each of their departments. I setup OMW in such a way as to make it easy for them to create their versions in Dev and promote them via OMW. Before Xe the CNC used to try to maintain the versions and the users at that time wanted a version of each report for every facility (300) Now that they are maintaining versions we have 1 version/user/report. So it has worked out well for us. I created a manual for them and have attached it.

 

[kjjdelist]

Zoltan, I think you are pointing me in the right direction.
Two scenarios:

1) If a user checks in a version (assume in PD, so goes to PD and DV) and then I promote it from DV to PY, will the user have it in PY or does it need to be deployed? I know that the Proc. Options are dynamic (User 1 changes, User 2 sees the changes) but what about the Data Selection? What if it's a new version? Do I need to promote it on to PD and then deploy to all 3 environments?

2) Using Activity rules, can I make the systeme check in to LOCAL, DV and PY all at the same time? I know this will automatically push any changes in DV to PY, but I think that's OK. this will keep me from having to promote any changes unless they're made in DV or PY, then I have to move to PD when tested. What would be the harm in this? The first scenario also applies to this I suppose.