The continuous delivery journey is pretty exciting, but we need to all embrace it to get the most out of it.
Planning your adoption of continuous delivery is really important too, making sure firstly that you are on 9.2 and then setting an update cadence that you are happy with and a schedule that you are going to stick to (schedule of applying ESU’s and tools releases).
You need new tools and new thinking to enable this journey, here are a couple that I’m recommending:
- understand your ERP usage better. Understand the programs that you are using and more importantly the modifications that you are making. subscribe to ERPAnalytics from Fusion5 to really understand your users and modifications. Use this data regularly to understand the retrofit and impact analysis of the new round of continuous delivery.
Screenshot above from ERP analytics showing you what applications are being used.
We can see the applications that are being used, we can download this to excel and cross reference this information with the JD Edwards manifests from the ESU’s. Note that we can use something like powerBI to read this “realtime”, actually read in the ESU release notes or farm the JDE tables for what objects are affected and then produce a really nice neat powerBI dashboard of ACTUAL IMPACT – which allows you to streamline your continuous deployment!
- Seeing the differences in the code. Wow, have I got something cool for you. Imagine that you wanted to see the actual form control differences in your code between environments? We’ve written some pretty nifty code to allow you to do this VERY easily.
- So, you can see that the output from the above is all of the programs in JDE that you use – simple – export a spreadsheet
- Now extract all of the changed objects in the ESUs that you want to apply (from impact analysis) – easy!
- cross reference the above so you know what has changed and what has not
- Now – run our code to give you all of the changes between the objects in DV920 vs. PY920
What does this magic do?
Basically you can provide a number of AIS end points and his code will spit out ALL of the differences in the objects that you select in a CSV (or JSON) format.
For example: two different AIS sites were compared and for this form W1701A (control number 571) we can see that it exists in site 2 and not in site 1. We can see that this is parent number, data type 9, visible etc. Cool? Yes – this is very cool!
· Think of a comparison for users security and evaluating whether they can see forms or not. (editable). so really – think about this. You could run this program as a series of different roles and users and actually determine what the users would see on the forms!
· Think of identifying modifications a little better.
· Think of comparing environments that have had ESU’s applied
· Different DD’s, vocab overrides and MORE!
We can feed this software (command line executable) the results of ERP analytics to only look at the objects that have changed for a client – honing in on exactly what they need to know to support CD.
I’m sure you might be able to think of other uses, but if you want a copy of a demo – please reach out.
All clients need is an AIS server and we are away. We can bring one in [AIS server] (as a VM) if needed and run it off that too.
restore the package from the zip file
install node - from here https://nodejs.org/en/download/
goto restore dir with command prompt
npm i --This will install dependancies
C:\temp\compareStuff>node app --help
Usage: app [options] [command]
compare <formName> [additionalFormNames...] Compare two different forms.
Example compare P4210_W4210A --format csv --out P4210_W4210A.csv
-h, --help output usage information
-V, --version output the version number
--format <format> Specify the output format. Allowed: "csv,json" (default: json)
--out <file> Write to a file instead of the command line.
Config is in
Sample csv output is above.
So that is a couple of pretty neat productivity ideas that will get you closer to continuous deployment of Oracle’s continuous delivery.