How to attach a service to HTTP port/listener

Hello,

we’d like to define a HTTP port in IS so that whenever a request is received through that port, a service (which we’d specify in a kind of config) is called. The service should get the request data as the input parameter.

How is that possible? In the IS Admin Guide I could only find how to configure a HTTP port, but not how to attach a service to it.

Only one service should be callable through this port, i.e. this should not be a general port like the default one where it’s possible to call an arbitrary service via “…/invoke/…”.

I’m not sure whether this is the right forum for this post. Another candidate would be “Protocol and Transport”, but I’ll try here first and then may be there.

Thank you for your advice!

Hi,

define the Port as “Deny by default” and add the service you want to the allow list.

The service still needs to be called by the “…/invoke/…”-pattern.

If you try to call any other service it will not be possible as the port blocks this.
Only the services in the allow list can be called on this port.

Regards,
Holger

Hello,

thank you for the quick reply.

How would you do that? Via ACLs?

UPDATE: I’m sorry, I should have not asked that since I could find out it myself. The only point which might still be unclear is how to propagate this definition from one server to another.

Hi,

you can use Deployer for this.

Specify the Port as the artefact to deploy.

Refer to the Deployer Users Guide for details.

To answer the original question (might be of interest for other members too):

After creating the port this can be configured in the Access Mode section.

Refer to the IS Administrators Guide for further settings which can be applied to ports.

Regards,
Holger

A port can also be associated with a specific package, meaning that when the package gets deployed, so does the port.

Percio

By the way, if you wanted to mask the …/invoke/ part of the URL so the user doesn’t necessarily know what service he’s calling, you can use URL Aliases under Settings.

For example, you can create a URL alias called ‘myService’ with the URL Path set to ‘pub.math:addInts’. Then, going to http://:/myService?num1=1&num2=2 is the functional equivalent of going to http://:/invoke/pub.math:addInts?num1=1&num2=2

Percio

Thnak you all who responded!

I’d like to refer to the original post and ask whether the service could get access to the request data, not just to the parameters specified in the URL (for GETs) or encoded in the body (for POSTs).

I.e. if the data contained in the HTTP request is some binary data (for example) or an arbitrary string (e.g. JSON): is it possible to access it?

So, you want to access the raw data that came in the HTTP request, correct? I personally have not had a need for this and I am not aware of a built-in service that provides that to you. getTransportInfo is the closest thing but it only gives you the HTTP headers.

If I had to guess, you will probably have to write a Java service that starts by grabbing the InvokeState, then gets ProtocolInfoIf, casts it to an HTTPState, and then retrieves the data from that object. What I’m not sure about is whether you will be able to read the HTTP input stream again since by the time your Java service gets to it, it will already have been read by the IS’s content handler.

Good luck though,
Percio

Thank you Percio for your thoughts. Yes, I’d like to get access to the raw data of the request. And your words confirm my assumptions.

As of now, I think my best option is to define a service with a single parameter of type e.g. byte array, and to tell the senders to send their data not as the raw data but to wrap it into a POST request with encoded form data or something like this. I wouldn’t like to dig deep into the IS processing chain since it is not supported and also not guaranteed to work.

I’m curious as to why you need to do this at all. In 12+ years of working with webMethods, I have not had to do this before. Can you elaborate more on your requirement?

Percio

We’ll get requests handed over via HTTP with a header of a fixed structure and variable contents after that. I’d like to create a generic service which would look into the header and do further processing depending on its contents.

In order to do that I’ll have to analyze the raw HTTP data since it’s planned that it’s sent just as raw data and not as e.g. file attachment of a HTML form.

How would you handle that?

I was a bit surprised to not to instantly find a built in feature for that. I’d expect a feature to exist which would work similarly to e.g. file polling or MQ adapter. There, when a request arrives, a service is called and the raw data of the request is passed as a parameter.

Will the content-type header be static at least? If so, then you may be able to accomplish what you want via a custom content handler. The IS Admin guide has some info on content handlers. If you can control what content-type the consumers set, you may even be able to leverage one of the existing content handlers that place a contentStream object in the pipeline. This option coupled with the output from getTransportInfo is the closest thing I can think of in terms of out-of-the-box functionality to what you need.

Once you get a chance to read up on content handlers, let me know if you think they would fulfill your requirement. If not, we can try to come up with something else.

Percio

1 Like

That will be the way! I’ve tried already and see that, if I set the content type to e.g. “application/soap” I get an input parameter “soapRequestData” with the whole message.

This is documented in webMethods Integration Server Administrator’s Guide, section ‘Content Handlers for HTTP and FTP Requests.’

You can write a custom gateway service which will get the protocol and content type info using pub.flow:getTransportInfo serive.Once you get the content type you call appropriate content handler services and process the data received via the call.

Could you elaborate on this? Because my understanding of the picture is a bit different. The handlers are called automatically by the IS depending on the URL and request headers. As Percio wrote, by the time the request hits the service the request might have been already read and parsed.

What do you mean exactly when you say “you call appropriate content handler services”?