Orchestration client, clear cache and architectural options for high integration

This is a quick and technical post about cache and AIS servers.

One of my clients was complaining that then they used orchestration client (to call an orchestration) - it always picked up the new changes, but when they used postman (to call the same orchestration) - the changes were never in the resulting payload.  I (of course) stated that this was impossible and that the calls from postman do exactly the same thing as orchestration client and my customer must have been wrong...

But, it seems that there might be a large amount of egg on my face, for two reasons.

1. Architecture
2. cache clearing

Architecture

When we set up orchestration studio and AIS, Fusion5 generally create a couple of instances of each.  The reasons for this are that we have a bunch of mobile applications using AIS, so we want them to come into their own AIS instance, then then points to it's own dedicated HTML server.  Makes sense?  Yeah!  This is also complicated by the fact that we have a custom domain which points to an AWS ELB which points to a nginX server, which proxies the actual traffic!  YAY.  IT is actually a really nice setup. 

We do the above so that we don't have funny ports in our URLs and we can do HTTPS offload.  Some simple nginx commands can serve up all of the environments from a single server on 443 or 80 - this is really nice and neat.  If you have crazy ports in your environments - you need to stop - browsers are shutting this down pretty quick.

Oh, the OTHER AIS instance pair is the HTML server that all normal users log into, and of course this needs an AIS server now for all of the watch lists and other items.  So we create these separately.  This IS the instance pair that we hook up to orchestration too.  See my confusing diagram below. 

So orch needs an AIS server, which points to an HTML server which points to an AIS server (I personally think that this is stoopid).  You get double connections on all of your HTML servers now because of AIS connections.  So you need to double your "maximum  users" setting in JAS.INI because of all the extra sessions...

Anyway, I'll stop complaining and get back to the issue...  

I think you can tell from my explanation above, that the external postman link was pointing to 1 AIS server (9062) and orchestration studio was pointing to another (9052).  This was a fundamental architectural reason for the cache not being cleared on the AIS server, but this was not the only reason.

Diagram showing multiple servers and their purpose and relationship

cache clearing

The second reason was that when you log into the orchestration client, it clears the cache for the AIS server that it is part of - magically.  So, when you run any orchestration from the client - it picks up the latest version of the orchestration - nice.  But, if you are not logging into the AIS server client component - then the cache is NOT being cleared.  Therefore postman is picking up some old crap and displaying it.

All that needs to be done is that someone needs to login to the client component of the AIS server behind the proper domain name (9062), and BOOM the cache is cleared.

We could also give our client a cURL command or something that would force the cache clear too - essentially pressing the clear cache button from the client.

These are my cache settings, cache is not enabled - but it's certainly on!

So, case closed.  We provide linked to the AIS client that is being exposed externally, client logs into said orch client (9062) and the cache is cleared and postman shows the correct data.

Average JDE web performance - literally

Are you fast or slow?  How can you tell if there is a little bit more that you can possibly extract out of your ERP?  Performance is generally a subjective thing, you lull your users into a sense of good performance and bad performance based purely on precedence.   <!--[if !mso]><![endif]

I'd like to see this analysis extended to an objective analysis, and this is precisely what we have done for JD Edwards using ERP analytics.

We deploy Google Analytics as part of the tools release.  This then sends a tiny amount of javascript to the client to execute on certain HTML events in the client browser, for EVERY page for EVERY user.  This does sound like a lot, but we've done a significant amount of performance testing with this and have noticed an immaterial different in performance and traffic.

We have this solution running for about 50 clients in Australia and around the world.  Our clients are able to benchmark performance AND productivity, then measure any delta's caused by change.

So I thought that I would reveal some pretty cool findings.  We've analysed over 32,000,000 page loads and over 1,140,000 logins (sessions) for the table below.

This is the last 100 days of data for approximately 26 active JDE clients, all anonymous of course.

I'm graphing 2 metrics here:

Avg Page Load Time: The average amount of time (in seconds) it takes that page to load, from initiation of the pageview (e.g., click on a page link) to load completion in the browser. 

Avg. Page Download Time : The time to download your page

Personally this is pretty impressive.  On average JDE users are accessing 29 pages per session.  That is pretty interesting.  

On average the page download time is .05 seconds - tiny

On average the time it takes to load a page is .86 of a second - pretty good too, on average we have a sub second response time for JDE as a ERP.

If your site is taking longer than that, you are not reaching your potential.  There are some pretty quick fixes for a lot of these issues, which will ensure that you are getting the most out of your hardware and users.