OIC and JDE - the perfect mix (like oil and water)?

I recently did an OIC bootcamp, oh man.  There was so much I liked about the product.  In terms of an integration platform - it seemed to be really well thought out.  I love the fact that you could add human interfaces to integrations to make decisions.  That's right - web forms and human interaction on the fly for an integration!  That is nice.

I also really liked the native connections to VBCS and the fact that if you were running cloud ERP of any of the other oracle cloud products - it seems silly if you are not using Oracle Integration Cloud as part of (or all of) your integration solution.  So much so that we are strategically recruiting in this space and want to own customers cloud ERP integrations.

Though, this is a JDE blog and I want to comment on the JDE connector that is available with OIC...  I was just about to start writing accelerators for linking Cloud ERP data with JDE data.  I was ready to create synchronisation of popular transactions - potentially starting with financials.  This was going to be the foundation of capability.  Modernising my teams consulting skills from JDE to Cloud ERP.  An accelerator for customers to migrate their data and run things SBS - side by side.

Then, it hit me...

Nice interface...  Love the drag and drop.  Love the fact that the orchestration studio developers MUST be working with the OIC team, because this all looks too cool and too similar!

This is really neat and a well thought out design.  Like I said though, similar to orchestration.  And what do people find frustrating about orchestration (especially hard core developers) - the lack of smashing a keyboard.  We love writing code, finding code, massive changes...  we love regex...  The above does not give you much love for this.

But, I digress.

I want to create a connection and I need to use an adapter (of course, an API is harder to create and the generic rest connector looks way too "RESTY" to me (and if you know JDE's implementation of rest, you will support me here).

Looking at the details of this connect (can't WAIT to paste in my discovery URL or perhaps the swagger or OpenAPI definitions of all the orchestrations I want to call...).

Getting excited...

Nearly there!

Huh??  WSDL??  SOAP...  BSSV... Oh no...  I'm crying all over my plans to take over the world...

I need to get my team to write a connection to REST-ify calls to JDE.  This could be done.

If you need to expose some relative resource URIs and wrap them up into some funky orchestration calls...  Otherwise this is not going to be an amazing integration.

Anyway, I'm going to fight the good fight with the REST connection to see if I can get some orchestration calls working.  I'll be sure to post how I go.

But, OIC - please modernise your connector for JDE to support orchestrations.  PowerApps does it SOOOO nicely.  I know powerApps is not an integration platform, but you know what I mean.

JD Edwards on AWS - with all the fruit

Fusion5  did something amazing about 3 years ago - before we thought it was possible.  We created an elastic JD Edwards in public cloud that used ephemeral pods to run JDE workloads.  This incredible architecture allows the JD Edwards server count to expand and contract with the requisite user demand.  So, as people log in... servers expand...  

Then as demand wains, then the servers also contract - but they contract ONLY when users and batch jobs have finished running on them.  The entire architecture is aware of itself.  The architecture is bought up with all signals being monitored (bespoke ones too - connected users, running UBE's) and these signals are interpreted for expansion and contraction rules.   All of the standard CPU data can be used to trigger any actions with the architecture too.

What does this allow us to do?  Well - once again, let's let the picture do the talking...  We can see that on any given day, how many users logged into JDE and how many unique ephemeral hosts were started to process that load.  We have a cost from AWS in the table [oh yes! this is the public cloud that I'm talking about in this instance], which is the actual costs for the class of machine that is running the pod workload.  We also have the average server response time listed, which is critical for us to determine if the number of servers is appropriate or not.

Finally you will see the mesmerising (oh yes, I think it is!!!) pattern of host growth (bar) vs. connected users (line) which track each other exactly over the month period.

Now, I have the ability to test different hosts, different tools releases, different OS's if I want.  I can release that POD into the farm and measure how it performs.  I can change the server class or anything and know the exact impact that this has on JDE.  I also have all of the logs coming back to a central cloud console (in AWS of course) to do my troubleshooting on.

This is by far the most elegant and easy to manage JD Edwards instance I have ever worked on.  Do you want yours to be this cool?  reach out!

\

JDE oracle licence audit, again and again

There are numerous ways of interpreting oracle licence audits, but my guess is that if oracle wanted to pursue you - you could get in trouble pretty easy.

I invite you  all to pull out your licence agreements and pay special attention to the definition of an application server.  This is someone that is authorized by you to use an application regardless of whether they are using the application.

If you take this as a lawyer would, I would argue that you do not authorise people if you leave security all doors open.  The words and context of this definition seem to imply an active act of authorisation.  This is not active authorisation, you have not performed any actions to authorise.  But - if you lock everything out and then start to authorise back (all doors closed), then you are opening yourself up for issues.  Therefore a solid security model where you are actively allowing people to use JDE programs, you are going to need to ensure that the end users are licenced.

It's strange that this 2010 definition then goes into breaking down particular modules and transactions.

Just testing of the definition has survived the test of time: from https://www.oracle.com/a/ocom/docs/license-definition-rules-v091120.pdf 

Application User: is defined as an individual authorized by You to use the applicable licensed application Programs which are installed on a single server or on multiple servers regardless of whether the individual is actively using the Programs at any given time. If You license the Oracle Self Service Work Request option in conjunction with Oracle Enterprise Asset Management, You are required to maintain licenses for the equivalent number of Application Users licensed and You are granted unlimited access to initiate work requests, view work request status and view scheduled completion dates for Your entire employee population. Application Users licensed for Oracle Order Management are allowed to manually enter orders directly into the Programs but any orders entered electronically from other sources must be licensed separately. For Oracle Sourcing, Oracle Fusion Sourcing, Oracle iSupplier Portal, Oracle Fusion Supplier Portal, Oracle Services Procurement, PeopleSoft eSupplier Connection, PeopleSoft Strategic Sourcing, PeopleSoft Supplier Contract Management and JD Edwards Supplier Self Service Programs, use by Your external suppliers is included with Your application user licenses. For the purposes of the Oracle Financial Services Operational Risk Solution Program, employees who are just contributing information to the Program via the applicable user interface shall not be counted as application users

So yes, seems the same.

Given the above two definitions, it seems that the best thing you can do to avoid any problems is to ensure that you have the appropriate security in place which will enforce your licence metrics.  The old saying that "enterprise licences" prevented audits is not right, as an enterprise licence is generally only for a certain number of modules.

Short addendum - Enterprise Metric:

Enterprise licences can allow customers to have any number of users using JDE and they only need to pay a certain amount of fees based upon revenue of their business.  There are generally additional provisions for additional revenue - i.e. if you increase your revenue over the number listed - you will need to buy additional units.

For example, a customer might have a table like the above.  It means that they can have heaps of users, but will pay oracle based upon the perceived revenue number above (313 $M).  They will pay a fixed fee to oracle based upon this number.  Note that this is only for 19 named modules, not all of the JDe modules.

If the revenue goes above this, then they'll need to "top up" in increments that are generally listed in their licence agreement.  The increments are generally in tranches, therefore if the revenue is above the 313$M and in the next tranche (156$M), then they'll need to pay the additional amounts.