Change control in the new world of E1 components



Reputable Poster
With the release of the IoT Orchestration component in the new tools I'm curious how JDE sites are going about managing change control in this new world and the dependencies between objects that are managed in OMW and the ones that are not. I know the capabilities of OMW will be increasing to incorporate some of the new elements but the new features are constantly introducing new technology which doesn't fit inside the classic E1 view of objects.

Is it time to start looking at more generic approaches to development and change control within JDE and all of the ancillary components? Can you combine Git, Gradle and Jenkins to manage the process of change across the different technologies?? Based on what is required to configure and manage the IoT Orchestrator I think things will need to change soon.

At the moment it seems like people are going back to the bad old days of pages of special instructions, manual checklists and uncontrolled deployment scripts built by one person in a dark room somewhere.


Well Known Member
Hello Russell,
It sounds like you walked out from the “darkest room” of our office on the release to production date.

I completely agree with what you are saying about deployment procedure for a modern jde environment and feel the same about our current promotion and deployment process – it is bad and not nearly as neat and simple as omw project promotion/build/deployment process. Because of the luck of the resources and expertise, we are struggling with keeping up with day-to-day business requirements and did not have a chance to standardize the development/promotion/build and deployment process.

I would say that we are rather small jde site but we have so many technologies implemented here: JDE, Weblogic (BSSV, RTE, Oracle Fusion Middleware (SOA and OSB)) and a couple of not really software development oriented platforms: Transform (printing solution), EDI Integrator. I could have forgotten something.

As for now, we have achieved partial control over software development life cycle process. I would call this approach “reactive”.

Obviously, we use omw and standard jde promotion/build/deployment process for all of jde standard object changes – this is the simplest part.

The nightmare begins with all the objects that are not controlled with omw.

We were trying to use git for:
JDE source code “control” (specs exported to text files), jde source code is exported every week and committed to a repository. Every jde source code change has comments with a change request id # that can be used for changes tracking purposes.

Oracle Database objects DDL (table definitions, triggers, custom views, sequences, etc.), same as JDE source code – just reference and tracking of changes.

Oracle Fusion Middleware source code control, it fits perfectly in git as it is just a bunch of text files (xml, xsd, wsdl, etc.)

The darkest part is the orchestration of the promotion/build/deployment process. The biggest challenges are concurrent development of the different requirements for the same objects and multiple dependencies that must be met during deployment and execution of a solution. There have been multiple times when somebody forgot to include a particular file or included old version (from SOA/OSB) or setup definition (for Weblogic jms queue, etc.) into the build script and after deployment solutions failed to start or worked not properly.

After almost 2 years of struggling with ”special instructions, manual checklists and uncontrolled deployment scripts” we have realized that we need some changes to improve the process. As usual we did not have time to implement standard process for a heterogeneous jde environment (is there one?). We tried to address the issue with multiple dependencies between development objects using Dependency Structure Matrix. It is very simple concept that helps us control small projects (Change Requests) and dependencies between them.

Every single development object: jde app, ube, bssv, soa composite, osb, etc. (including projects/Change Requests) in our environment has unique name. All the dependencies between objects are controlled with DSM. DSM is used to build dependency report that can be used for different purposes. Firstly, it shows all the objects involved in the development of a particular project and can tell if we can start new development project and what are the collisions in the dependencies between competing projects. It can be used as reference for the manual build process, and helps to keep track of all the objects involved in the build.

Wow the post is getting bigger and bigger.
Please find some screenshots below showing the concept and let me know if this makes sense for you.

Maybe there is a magic bullet for this kind of issues and we do not need to reinvent the wheel.

List of objects (projects, objects, etc.)


Dependence Report


  • dsm1.jpg
    20.3 KB · Views: 13
  • dsm2.jpg
    30.7 KB · Views: 10
  • dsm3.jpg
    45.3 KB · Views: 10
Last edited: