Deploy/ Undeploy ISD - what really happens under the covers?

Dedicated to DataStage and DataStage TX editions featuring IBM<sup>®</sup> Service-Oriented Architectures.

Moderators: chulett, rschirm

Post Reply
ffsw13
Premium Member
Premium Member
Posts: 31
Joined: Mon Feb 01, 2016 10:29 am
Location: USA
Contact:

Deploy/ Undeploy ISD - what really happens under the covers?

Post by ffsw13 »

Ok so I've scrubbed the IBM docs before coming here to ask, in my opinion some form of this should be documented, if it is please point me there. Here goes:

I get it when ISD applications are deployed, The services are generated along with additional artifacts, depending on the binding that was selected. and picked up by WAS to run. What I am wonder is what happens when the applications UNdeployed? are the services simply run down? and when the the app is re-deployed, does it just update the services that were there already and re-start them?

On a related note, since the docs don't really give you a good idea on how to wind everything down and spin it back up in terms of the sequencing, I'll take a stab at it and please course correct me as required:

Shutdown sequence for a given app:

1. disable the information providers (in this case DataStage jobs) for a given app you are about to undeploy (which if it's DataStage the always running jobs should stop running verifiable in Director).

2. undeploy the application


Startup sequence for a given app:

1. deploy the application (if new services created they get deployed)

2. enable the information providers for the given app you just (re)deployed (which if it's DataStage the always running jobs should now be running verifiable in Director).

DataStage Engine re-cycle:
1. disable the information providers (jobs) so the jobs stop running

2. DataStage engine is shutdown and re-started

3. enable the information providers (jobs) so the jobs start running


Information Server recycle:

1. disable the information providers (jobs) so the jobs stop running

2. re-start information server via the standard shutdown sequence which is DSEngine first, ASB agents next, WAS third, and the Repo tier if required. Restart, sequence is reverse of what I just described.

3. ISD and it's apps and services should all be running automatically after the IS restart, no need to manually enable information providers?

TIA,

ff
The UNIVERSE is vast and expansive
I never Metadata I didn't like
qt_ky
Premium Member
Premium Member
Posts: 2895
Joined: Wed Aug 03, 2011 6:16 am
Location: USA

Post by qt_ky »

I don't know about the details going on under the covers.

I'm not sure what is meant by "disable the information providers" then undeploy. I think undeploy is the only step. When you undeploy the ISD applications, then ISD automatically stops the associated DataStage jobs. You can confirm that in DataStage Director. Every now and then if something unusual went wrong, I have seen where the ISD undeploy step leaves jobs up and running. In that case manually stop the jobs or kill their processes.

Already-deployed ISD applications do automatically restart themselves after restarting Information Server or after rebooting the server. The drawback to the ISD applications automatically starting is that the previously running instances have a status of "crashed" and after several server restarts, the status view in DataStage Director becomes cluttered with all the crashed instances, but it all functions OK.

Since I don't like the default behavior and want it to be cleaner, I had scripted ISD stop and start commands that we call from our overall Information Server stop and start scripts. Order-wise, stop ISD apps first before stopping the DataStage engine. Please see my post of a sample script with ISD deploy / undeploy commands:

viewtopic.php?t=144561
Choose a job you love, and you will never have to work a day in your life. - Confucius
eostic
Premium Member
Premium Member
Posts: 3838
Joined: Mon Oct 17, 2005 9:34 am

Post by eostic »

Hi all.

I don't recall the "exact" internals, but when you "deploy/undeploy" you are starting the generation of a formal WebSphere Application Server (WAS) EAR file. Without crawling into the detail, this is a zipped up collection of stuff that makes up a J2EE app. You should endeavor, if possible to NEVER need to undeploy or redeploy. It's too much work, and opens you up for risk of error if you accidentally change something.

Disable/Enable just stops and starts the Job.

You "must" undeploy and redeploy if you change the signature of the Operation (the input and output columns that go to/from your Job), or if you add new Operations to an existing Service or Services to the existing application. Frankly, watching this closely over the years, even though you are able to define 1:many, I have found it a good best practice for maintenance and development to have a 1:1:1 relationship between the Application, the Service, and an Operation. ISD applications "generally" have only a few Operations, and doing it this way means you never have to worry about notifying people testing that you need to "take down the service" to add another Operation.

A practical use case discussion may help here. Imagine a service that takes an incoming product code. The DataStage/QualityStage Job validates it, maybe performs some transformations, performs a lookup, and then returns details about that product. If you establish and agree upon your "signature" (let's say it is prod_code going in and productionCode, Description, Price, quantity being returned), you can create a dummy Job with ISDinput - Transformer - ISDoutput and deploy the Job. Just have the Job send back a dummy output row that is hard coded inside of the Transformer. Get the Dev and QA people testing and building their external SOA application.....while you work on the Job. You can change the Job 100 times and never redeploy. It can have just one stage, or 200 Stages in it.....if you leave the signature alone, all you need to do when needed is "disable", re-compile, and "re-enable".

Hope that helps.

Ernie
Ernie Ostic

blogit!
<a href="https://dsrealtime.wordpress.com/2015/0 ... ere/">Open IGC is Here!</a>
qt_ky
Premium Member
Premium Member
Posts: 2895
Joined: Wed Aug 03, 2011 6:16 am
Location: USA

Post by qt_ky »

The console has buttons and tasks labeled Deploy and Undeploy but not enable or disable. How would one achieve the enabled or disabled state?
Choose a job you love, and you will never have to work a day in your life. - Confucius
eostic
Premium Member
Premium Member
Posts: 3838
Joined: Mon Oct 17, 2005 9:34 am

Post by eostic »

In the Deployed Applications Workspace, click edit (lower right) after highlighting the Application at the upper left....then the enable/disable button "appears".

Ernie
Ernie Ostic

blogit!
<a href="https://dsrealtime.wordpress.com/2015/0 ... ere/">Open IGC is Here!</a>
qt_ky
Premium Member
Premium Member
Posts: 2895
Joined: Wed Aug 03, 2011 6:16 am
Location: USA

Post by qt_ky »

Thanks for the tip. I've been using ISD since 2012 and never knew that feature existed!
Choose a job you love, and you will never have to work a day in your life. - Confucius
eostic
Premium Member
Premium Member
Posts: 3838
Joined: Mon Oct 17, 2005 9:34 am

Post by eostic »

Glad you found it. Unfortunately it isnt intuitive. In the old RTI it was more prominent, maybe even a right click option....but that was 10+ years ago. ; )

Ernie
Ernie Ostic

blogit!
<a href="https://dsrealtime.wordpress.com/2015/0 ... ere/">Open IGC is Here!</a>
ffsw13
Premium Member
Premium Member
Posts: 31
Joined: Mon Feb 01, 2016 10:29 am
Location: USA
Contact:

Thanks.

Post by ffsw13 »

Thanks everyone, just what I was looking for, much appreciated. I will mark this topic as resolved and just say in closing that it is easy to grab the WSDLs once an application is deployed, the XSD's where a little harder to find, I ultimately found them in /installRoot/IBM/WebSphere/AppServer/profiles/InfoSphere/installedApps/HostNameNode01Cell/ISD_QSStan.ear.ear/QSStan_SOAPOVERHTTP.war/WEB-INF/wsdl/
The UNIVERSE is vast and expansive
I never Metadata I didn't like
Post Reply