It's so nice when you are old and get to feel productive. This has been a phenomenon when doing lots of JDE on AWS.
AWS have an amazing cli interface in which you can script everything.
Orchestration in JD Edwards allows you to create an API out of anything you want to do in JDE…
Finally, cURL is an amazing utility in linux.
Oh, and have I mentioned, I have a black belt in ksh and awk ?
So, you add all of this together, and I'm getting productive.
We are doing some funky things in JDE to bring it out of the dark ages and into a CI/CD pipeline on AWS. This does take time, but we there.
For one scenario we have created some highly available batch servers that can be replaced when there is a new package deploy, that's right – they are ephemeral.
So, to enable this (not to give too much away), there has been a lot of work by SvdS and myself – mainly SvdS – if you are in the game – you know who this is.
We have a fixed IP that we can attach to the server when it becomes the new server, but to make this smooth – we need to disable all of the queues on the original. Make sure no batch jobs are running and then move them over.
So an orchestration to hold all the queues, that makes a lot of sense. An orchestration to release all of the queues and an orchestration to run some batch jobs – just to make sure that things are cool (and reconnect the web server to the new machine).
Let's do it:
holdAllQueues is an orchestration that I wrote (I'll include it for download) that you can enter a hostname and it'll hold the queues, wow – simple. But have you done this manually, painful!
If you want to call this in a ksh, then:
#!/usr/bin/ksh
set -x
if [ $# -ne 1 ]
then
echo "USAGE $0 SERVERNAME"
exit 1
else
serverName=$1
fi
echo ${serverName}
data='{"MYLOGICHOST":"'"${serverName}"'"}'
echo ${data}
#exit
curl -v --request POST \
--resolve au.jde.something.com:443:10.116.23.100 \
--url https://au.jde.something.com/jderest/orchestrator/orch_fusion5_holdAllQueues \
--header 'Accept: */*' \
--header 'Authorization: Basic WU9VQVJFOkFCVVRURkFDRQ==' \
--header 'Cache-Control: no-cache' \
--header 'Connection: keep-alive' \
--header 'Content-Type: application/json' \
--header 'Host: au.jde.something.com' \
--header 'accept-encoding: gzip, deflate' \
--header 'cache-control: no-cache' \
--data "${data}"
The reason that this might help is the passing an environment variable (or parameter) into cURL can be curly (like that?).
So you'll see that this simple example conversion parameter 1 from the script input as the servername in the JSON body to the orchestration that I wrote.
The other thing I have in this example is avoiding certificate problems with the –resolve option, this is great because for many reasons, these addresses are no internally resolvable. (it's me not you).
So, this shows you how to use shell variables and create a really handy function to hold all of the batch queues – perhaps before a package deployment.
This allows me to move IP's to the new machine and then start loading it up with more batch jobs without an outage – YAY!
