Hi Experts,
I have a requirement to execute a set of JAVA services from one IntegrationServer(kind of Monitoring server) to other IntegrationServer(s).
This is required to get the health status of the respective node(s).
I have a working JAVA code snippet, just need help in executing it remotely.
Thanks in advance !!
Best regards…
Abhishek Jain
Hi @Abhishek_Jain ,
If you have a remote server alias configured in your source IS , you can execute the services on the target by invoking pub.remote:invoke service passing the remote server alias, service name as inputs. The IS Built in services guide should have more information.
-NP
Hi Abhishek,
in addition to Nagendras response you might want to check for the CommandCentral and/or Optimize for Infrastructure features for health checking.
Which version of wM are you referring to?
Regards,
Holger
Hi,
using Command Central as mentioned by Holger is the most straightforward way for healthcheck as you do not need to code but can do it by configuration. If you run inside containers, Microservice Runtime (MSR - that’s simply speaking a container optimized version of IS) gives you standard endpoint which can be monitored by the container orchestration
If you really want to invoke a java service remotely, as soon as you have it as a java service inside one IS, the pub.remote:invoke mentioned by Nagendra is the easiest way. But you may want to consider calling this by Soap or Rest, as exposing a service via any available protocol is quite simple and gives you more flexibility and standard conformance. It’s also easier to integrate it into evolving architectures, call it from other products or integrate it into API management.
Regards
Martin
Not a bad thing to consider. But everything is a trade-off. There are pros and cons to each of the approaches. Another approach is just plain ol’ http call (the invoke directive on the URL). The only option that has an existing standard is SOAP, and I would strongly discourage that path.
My recommended order of things:
Use CC or OFI in MWS. Avoid custom monitoring components if at all possible. Perhaps the OP can share exactly what is being monitored?
Use pub.remote:invoke to call the remote service. Be aware that the entire pipeline is sent to the remote server unless you take steps to limit the scope – like making the pub.remote:invoke call within a scope.
Call the remote service using pub.client:http and the invoke directive (rather than ws or soap or rest or rad). Doesn’t require additional components like WSD or RAD.
Call the remote service using the so-called legacy approach with the rest directive. Doesn’t require a RAD component. But if you think your monitoring functions may broaden, might be useful to use the RAD approach.
SOAP/WSD to me is a non-starter. We use this only when there is no other choice.
More often than not, guesses about what might be needed in the future are wrong. If you have a roadmap of what is to be provided for specific needs, great. But avoid doing things “just in case” or “might be useful in the future.” That almost never works out. Of course YMMV. 
Make implementation decisions based upon what is known, not too much on what might happen in the future.
Thanks for the response.
Yes, i have designed a framework using pub.remote:invoke.
My requirement is to run a custom java code(which checks and reports long running services ) from source IS to target IS.
We are working on 10.5.
Command central is a good option, but we have custom requirements.
The servers are in cluster and we have certain specific components to check throughout the cluster.
Like Schedulers, Connections, Listeners, Notifications, Ports, Pools, Unix mount points, and many other things. and on top of this, these details need to be sent over an email.
Most of these are working but i am stuck with few.
one option could be deploying the custom code on target IS, but I am not considering it as of now.
Management is not willing to add additional components. As mentioned earlier we have custom requirements and I am not much aware of the capabilities of CC.
I have built most of the things using pub.remote:invoke.
We are using wrapper services and are clearing the pipelines so i guess the whole pipeline is not moving to the remote server.
Only concern is with remotely invoking custom JAVA code.
To play devil’s advocate, if you’re not familiar with capability of CC (or Optimize for Infrastructure on MWS) how do you know you have “custom” requirements? I am very certain that there are existing components that can detect long running services. Indeed, Optimize can learn trends and report if runtime for something is unusual given the history.
As Nagrendra and Martin have noted, it does not matter in the least that the remote service is Java. All services hosted in IS can be called via pub.remote:invoke.
This infers that you’re looking to send the Java code to the target server and run it on-demand? IMO, just deploy to all the IS instances. There is nothing out of the box that will help with “push this code and run it on a target.” Create a package that you then install on all your instances. With Deployer this is trivial to do and will be more reliable. But perhaps I misunderstand your intent here.
HI Reamon,
Sorry for the confusion, but what i meant by Custom Requirements is like
The code I am referring to is not a built in one but:
Thread currentThread = Thread.currentThread();
ThreadGroup rootThreadGroup = currentThread.getThreadGroup();
while(rootThreadGroup.getParent()!=null){
rootThreadGroup=rootThreadGroup.getParent();
}
int actThCount = rootThreadGroup.activeCount();
Thread[] activeThreads = new Thread[actThCount];
String outputStr = "";
rootThreadGroup.enumerate(activeThreads,true);
if(activeThreads!=null){
for(Thread tempThread : activeThreads){
if(tempThread instanceof com.wm.app.b2b.server.ServerThread){
ServerThread serverThread = (ServerThread)tempThread;
String serviceName = serverThread.getServiceName();
String runningSince = serverThread.getStartTime();
SimpleDateFormat simpleDateFormat = new SimpleDateFormat("EEE, dd MMM yyyy HH:mm:ss",Locale.ENGLISH);
if(serviceName!=null && !serviceName.equals("")){
try {
if(runningSince!=null && !runningSince.equals("")){
Date runningSinceDate = simpleDateFormat.parse(runningSince);
Date currentDate = new Date();
long dateDifference = Math.abs(currentDate.getTime() - runningSinceDate.getTime());
dateDifference = TimeUnit.SECONDS.convert(dateDifference,TimeUnit.MILLISECONDS);
outputStr += " Service [ "+serviceName+
"] has started at [ "+runningSince+
"] and is running since [ "+dateDifference+"] seconds "
+ " isCancelled [ "+serverThread.isCancelled()
+ "] isAlive [ "+serverThread.isAlive()
+"] Status [ "+serverThread.getStatus()
+ "] state [ "+serverThread.getState()+"] \n";
}
} catch (Exception e) {
// TODO Auto-generated catch block
outputStr=e.toString();
//e.printStackTrace();
}
}
}
}
}
I was expecting to run it from Monitor server via pub.remote:invoke or some other utility like we run the built in services remotely, but I think I have to deploy this in target nodes and then I can run from Monitor server.
Please suggest if you have any other approach to check for long running services.
Also, I have attached a sample monitoring report.
The utility will run at a scheduled time, extract these details, and send it over mail to all the stakeholders(there are few customizations required though).
Thanks in advance !!
MonMailSample.pdf (60.1 KB)
My 5 cents -
Pre-upgrade Analyzer
Command Central -
I reaffirm and strongly recommend adopting CCE, as a few people have pointed out already. We’ve invested in developing CCE over the years, and now it has evolved and matured across provisioning, monitoring, administration, maintenance/patching and upgrade.
In my view, it’d be criminal not to use its robust capabilities (it’s available at no additional cost for wM customers). Why don’t you play around with it, showcase the capabilities to management and win them over!
In addition, CCE offers a programmatic window into a variety of monitoring stats (examples in the screenshot) that many aren’t aware of, via this URL (http://hostname:port/cce/monitoring/state/instanceName). Even monitoring stats of remote servers (IS, MWS, etc.) can be gathered via a central CCE, with SPM installed on the remote machines; no code deployment is required.
Monitor -
Event Manager -
Other Options -
People have mentioned Optimize already, so I’ll skip it.
We have a tool that can perform and generate reports (CSV, HTML, XML, JSON) of automated code reviews (disabled services, naming conventions and 27 other checks). It is customizable and also has a CLI that’s pluggable into CI/CD or DevOps scripts. This is offered as a licensed tool with additional cost by our services division at Software AG. It’s called Integration Server Continuous Code Review (ISCCR) and it can work in conjunction with Unit Test Framework in CI/CD and DevOps worlds; write to me if you’re interested.
KM
Basis of all the suggestions I am more inclined towards CC now but will go through all these.
Thanks again for the help !!
Yes, that is correct.
It is a fairly exhaustive report but I wonder if anyone will really read it. More often than not, somewhat disappointingly I suppose, regular emails like this become noise and are ignored. Preferable, IMO, would be notification emails sent when something requiring action happens. These should be few and far between. Tell people when things are not as expected rather than regularly giving the same report repeatedly that likely never changes much and when it does, no one notices because it almost never has anything of interest. Just aspects to consider.
Kasi has made a compelling case for using Command Central. I too recommend investing time in that rather than reverse engineering how service execution is managed in IS. If you’re determined to continue down this path, though, try to leverage existing services in WmRoot (as Kasi also notes). I know we’re not supposed to use those but can help greatly in administrative items like this. If you see a stat or item in IS Administrator that looks useful, review the .dsp for that to see where that data comes from. Then you can at least leverage existing components as much as possible, and minimize custom code. wm.server.query:getThreadList might be interesting for you.
For long-running threads, in MWS look at Applications | Administration | Rules | Rules List. In that list there is “Integration Server long running thread”. Review that along with “LongRunningThreadCount by Integration Server” KPI to see if that may provide what you’re looking for.
The hurdle for using MWS and CCE for monitoring is the relative complexity of how it is all set up (e.g. “where in the heck is the setting that defines ‘long running’”) and settings to set. It can be frustrating. YMMV.
Depending on the “27 other checks” this might be of interest for environment I work in. Would you be able to share the complete list of checks? Or point to a document that describes the tool? Some cool stuff emerges from PS (that’s where TN came from, as I recall) so would be interested to see if this ISCCR tool is a fit. Snide note: glad to see they were sure to include the “continuous” buzzword that garners so much attention these days.
To play devil’s advocate, if you’re not familiar with capability of CC (or Optimize for Infrastructure on MWS) how do you know you have “custom” requirements? I am very certain that there are existing components that can detect long running services. Indeed, Optimize can learn trends and report if runtime for something is unusual given the history.
@riyasingh8835714 I’m not sure why you repeated a part of my earlier post. Perhaps it was unintentional?
Yes with CCE/template based it does lot of work OOB more improvised from v10.5 and above is capable to do all the HC and monitoring standpoint.
GL,
RMG
I hope this will work if we enable audit logging for services.
I have used multiple services from wMRoot. and I expect that if there is a change in the services of the wMRoot package, it will not happen before upgrading wM to the next version.
This service has fulfilled my requirement.
Thanks !!
Regards…
Abhishek
I don’t think that is a prerequisite. But do let the group know if you pursue this path and it works out.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
