webMethods

I want to execute a webMethods service (i;e flow service or java service) using a shell script.

With curl, I have something like this:
curl -u user:password http://ip:port/invoke/linkToTheService.
But it not fit my use case because it is based on http and I can not do a condition on the result to know if the script is successfully execute or not.

Do anyone know how I can achieve my goal ?

Why do you say that? It is an HTTP call. In the script, you’ll want to check the HTTP status code. And depending upon the HTTP body returned by the service that is called, parse the response body as desired. The format of the response depends entirely on what the service does – by default it will return HTML. But can return XML, JSON, delimited data, etc.

Side note: beware placing the user:password in the URL in a command-line. Anyone with the right access to the system can see that. There is a way to store credentials securely for curl to use. Refer to the curl docs on that.

Agree with @reamon ; all webMethods services are essentially lightweight HTTP APIs (We can argue if they are ReST or not). They can take XML / JSON input and can return XML / JSON output. You can capture the output in variable, parse it using jq or other tools to perform an action.

I would be curious to understand what is your overall usecase? Normally, I have seen shell scripts invoking webMethods to perform routine maintenance tasks such as Disable Listener of MQ Adapter etc.

I’ll argue that they are not because, in one view of the world, there is no such thing as a REST API.

Roy Fielding has noted at various times that the “REST” label has been hijacked to mean something other than how he defined it. REST is an architectural style, having nothing to do with APIs per se. But as an industry, as we seem to do a lot, we took a word that had one meaning and applied it to something else which only vaguely resembles the original meaning. Now we use REST API (or just REST more so than not) to usually mean “JSON over HTTP” and argue about the “RESTfulness” of URLs.

I’m interested too – why use shell scripts/curl? If there is automation needed, do it in wM IS!

1- At the first place I was thinking doing the execution based on a number like 0 or 1 and not based on the http status code. Thank to point out the checking part. Yesterday, I’ve changed my code to check the http status code.

2- Thank for the side note part. Actually I keep the credentials in the url for the testing part. Later I can remove it and use the secure way.

@CHIRAG & @reamon Here is my use case.

We have many wM services that we don’t want to schedule using the internal wM Scheduler. In fact we use an external automatisation tool (i.e Control-M). When we use a web service, often we get a timeout issue. That is why we ideally want something that is not rely on http.

So I want my sh script to call my wM services (i.e: flow service, java service) by not using http like it can be done with curl.

I’ve checked the WmPublic package but I don’t get anything relevant that can help me achieve my goal. I’ve found the service pub.utils:executeOSCommand. But it is not helping me at this time.

Any idea/direction on how I can achieve my goal ?

Did you try implementing an async service? Using terminal just to implement a scheduled service sounded like an overkill to me.

You can also create a publishable document, and publish a document to invoke the time consuming process from a webservice, notify the client after publishing a document, and then notify again after the work is done.

In fact, the scheduling part is/will not be done with the terminal or a script. We have a tool name Control-M that will do it. The actual need is to execute a service in the sh script.

I imagine there has been investigation to determine the underlying issue, because that would be the thing to do. Are able/willing to share details of the CTM job that is calling the service?
Edit: Is the job simply executing a shell script on the CTM agent server or is the job type a Web Services SOAP or Web Services REST job?

The only other way I can think of, though I’ve never done it, is to use an IS API client library – which IMO would be far more effort than it is worth.

As you may have seen recommandations - there are few ways to invoke a webMethods service. Basic question is - do you need synchronous invocation (which means control+m needs to know that service started, service ended, and if outcome of the service was successful or not; or control+m just needs to “trigger” the service and not wait for the outcome?

Well, ideally you want to fix the underlying issue with the timeout. Timeouts are always a strong sign for a deeper issue. So burying them somehow, will very likely create huge operational problems.

Unless something really fundamental has changed recently, I am not aware how this should be possible. Even the IS Java client uses HTTP under the covers.

What kind of services are we talking about?

Do you have an example or where can I found it ?

I’ll leave that as an exercise for you to locate the docs and such (as noted, I’ve never done this – never had a need). I strongly suggest to not go down that path. Get the HTTP working/reliable.

Using curl, below is what I have. It is working but I don’t want to rely on curl or http to do the service execution.

#!/bin/sh

SERVER_URL=http://IPAdress:5555
USER=CC
PASSWORD=CC
SERVICE=CCPackageName.services:myService
FULL_URL=$SERVER_URL'/invoke/'$SERVICE

if ! command -v curl &> /dev/null
then
echo "Error: curl is not installed or is not in the PATH."
exit 1
fi

OUTPUT=$(curl -I -u $USER:$PASSWORD $FULL_URL 2>/dev/null | head -n 1 | cut -d$' ' -f2)

if [ "$OUTPUT" = "200" ]
then
echo "Execution succeeded."
echo "HTTP STATUS CODE: $OUTPUT"
exit 0
else
echo "Execution failed"
echo "HTTP STATUS CODE: $OUTPUT"
exit 1
fi

NB: In the code the credentials are placing in the url just for the testing.

Not directly related but you shouldn’t use default admin port to execute services. Instead you should create a separate service port. If that port is overloaded someway (A DDOS attack or something) you will lose access to your admin UI. If that port is tightly coupled in your code, you can create a new admin port instead.

It makes sense in your use case to use external scheduler. Few thoughts: Do you have only one webMethods IS instance with this code? Do you have multiple instances? Are these set up as clusters? Do you have requirements to ensure it is only running 1 time ? or Can it run in parallel?

I am not sure if you are buying anything with shellscript. If the service has a timeout issue (I am imagining , it is either control+M’s timeout or webMethods server timeout that you are facing. With shellscript, It is adding another layer that reduces visiblity within Control+M.

IME, most jobs hosted in CTM are shell scripts. Certainly the different job types available are used but mostly people use shell scripts. Of course, experience/exposure varies so others may have different views.

As long as the script emits output for key activity/content, visibility of the job output is fine.