E9.2 Implement Version Control System with JD Edwards E1

I want to avail all the advantages of version control system with JD Edwards like:
1. Traceability - It tracks the contributions made by several developers. Tracking changes from the original copy to the many improved versions and, finally, to the final version.

2. Document History - It gives on the purpose of the changes made. It will have an impact on the developer that works on the latest version as it will help to solve problems experienced in earlier versions.

I have found this related document - Doc ID 2357415.1 for OL objects and Doc ID 2730335.1 for UDOs as far as first 2 points are concerned.

3. Branching And Merging - Version control allows team members to work on the same document concurrently but independent of each other without affecting the contribution of fellow collaborators. Each contributor works on an independent stream of change – commonly referred to as a branch.

I did not get any lead to achieve Branching and Merging or how to get developers simultaneously working on the same object as JDE is token based system. Despite so, is there any way of achieving VCS. I am open to ideas from all perspectives like -
1. If this can be achieved within JDE
2. If we need any third party tools to achieve this
3. Any manual/ auto way of achieving this

I'd appreciate if you could provide me any direction on this. All weirds ideas are also welcome!
 

Larry_Jones

Legendary Poster
The only type of object in JDE that Branching and Merging would be possible with is C BSFNs.

Since they should be kept in synch with other object types its a pointless endeavor.
 

BOster

Legendary Poster
Larry is correct. For about two years I used Git for all of our C BSFNs since I needed to maintain a separate branch too be merged at a later point in time and it worked pretty well. I basically ran this "underneath" OMW. However, it would get trickier with all the spec based objects/code.

There is a user on jdelist that does do some form of this for all objects including spec based objects so maybe they will weigh in.

Depending on your tools release you can turn on object versioning which I believe is what the documents you linked refer too. It effectively creates a PAR file stored by date every time you do a check in on an object. It is not as good as a real VCS like Git but it is better than nothing. You are not going to be able to look at a "commit" of all objects for example or do any type of merge from multiple developers. It is NOT going to allow for simultaneous development by multiple developers on the same object - a checkout/token of the object will still be required so effectively only one developer at a time can make changes to an object.

However, with it turned on, if nothing else, you can always revert to previous version(s) of a given object or use it to diff between two objects to see changes. With this turned on I have felt less of a need to comment out old code when making changes and instead can simply change or delete code knowing I can always compare with previous version(s) of the object or pull the old version if needed - makes code much cleaner not to have all this commented out old code. If you checkin all objects in a project at one time the timestamps in the OMW versioning will all be very close - that is about as close to a commit as you will get.
 

ONYX

Well Known Member
Thanks guys for your valuable inputs. Any idea that who this user is?
Hi amolchandane1,
Have a look at these. Hopefully, you will be able to work something out.
Oracle Support Document 2357415.1 (E1: OMW: Reviewing Object History and Export Specs in Tools Release 9.2.1 and Above) can be found at: https://support.oracle.com/epmos/faces/DocumentDisplay?id=2357415.1
https://docs.oracle.com/cd/E17984_01/doc.898/e14713/omw_scm_integration.htm
https://onlizer.com/bitbucket/oracle_jd_edwards

Unfortunately, I have never seen an SCM system integrated with JDE.
We are using git (bitbucket) to track jde "code extracts" produced by ObjectBrowser.
In our process we are exporting jde objects into text files after every jde check-in and pushing changes to git.
At least this gives us some of the SCM features like history, code compare, integration with jira, confluence which is good enough for us.
Obviously, this doesn't allow us to actually "manage the code", we are just tracking "code extracts"...

Hope this helps.
 
Top