Setting up OMW Rules

Any Good Documentation or tips on how to set up OMW Rules? We created an environment for our ESUs (ES7333) -for testing purposes.. I wasn't involved in any setup with the other enviornments.. Any help, tips or comments.. appreciated!
Thanks!

Angie Johnson
XE, Update7 SP22T_1

The class material from CNC Administration is pretty good.

Curious why you would need OMW rules for an ESU testing environment.

Let me see if I have this straight? You have an environment for ESU testing, correct?

1) Does this environment also include custom objects and versions? Or is it a copy of pristine that just gets ESU's installed?

2) If ESU's are installed directly to this environment, it must have it's own path code. How about it's own data set? Or does it share data with PY (CRP)? Not using an existing data set can only complicate the testing of an ESU, as data sometimes has an effect on processing.

3) Standard JDE | PSFT methodology states that ESU's should simply be tested in DV. If they don't work the way you anticipated, you roll back (assuming you installed with the B/U option). Is there a reason you didn't use this basic approach?

Your activity rules will take form once you've address questions like this. When you completely understand how this environment relates to the others, you'll be better equipted to design your rules. Since your ES7333 environment is custom, so will be you rules.

1) Does this environment also include custom objects and versions? Or is it a copy of pristine that just gets ESU's installed?

Answer: Yes it does include custom objects and version. It is a copy of production.

2) If ESU's are installed directly to this environment, it must have it's own path code. How about it's own data set? Or does it share data with PY (CRP)? Not using an existing data set can only complicate the testing of an ESU, as data sometimes has an effect on processing.

Answer: Yes it has it's own pathcode and data set.

3) Standard JDE | PSFT methodology states that ESU's should simply be tested in DV. If they don't work the way you anticipated, you roll back (assuming you installed with the B/U option). Is there a reason you didn't use this basic approach?

Answer: we decided to go with another pathcode for testing ESUs, as last fall we ran into a horable corruption problem where bits and pieces of ESUs got into Prod.. These ESUs, some had been removed, and others were just left in DV (big no no). After discussing with Developers, we felt that having a seperate environment for testing ESUs would help to avoid this issue. The ESU will be tested in ES7333.. when approved will be applied to DV and tested for a week (no development during this time)... then applied to PY and tested again in PY.. then to Prod. Once the ESU has been applied to Prod the ESU environment will be refreshed to the same status as prod.. ready for the next ESU.

Angie,

We use a separate environment for ESU testing as well and it has worked out very well. In addition to avoiding any problems with DV, developers can also continue to develop enhancements while ESU testing is underweigh (sometimes our update projects take months to complete, and we don't want to hold up enhancements).

I'm not sure what specific questions you have regarding OMW setup, but I can share our specific setup with you if you want to send me a private mail with the level of detail you're looking for. For instance, are you just looking for a high level what custom statuses did we create and our transfer paths or are you looking for details such as the activity rules below them? Let me know...

Yes that was another reason we went with another pathcode; to use for testing updates, SP, etc.(to not hault development while testing is in progress).

I'm basically looking for information on "how" to setup OMW rules as I have not done that before. Any guidelines you could give me would be great. You can e-mail me at [email protected]. Thanks!