Hello, it seems that while webMethods 10.5 has this function called pub.flow:HttpRequest, I can’t seem to find it in webMethods 10.7. What happens to that function and how do we access similar method in 10.7? Thanks
Hi there,
that service was actually a private service that was exposed by mistake in previous versions. You should only use the service pub.client:http
regards,
John.
@John_Carter4 Okay, but can that function get the current request’s header? Because I tried everything after attaching a custom key/value on the request’s header but none of the functions could do that, not even pub.flow:getTransportInfo. Any ways to do so?
You can also check my topic about it over here: Getting Request Custom Header value into Designer/Integration Server
You mean you want to add headers to the outgoing request ?
Easy just add them under input headers.
If you want to know what headers were received by a service being called from an external client, then you should use use pub.flow:getTransportInfo.
regards,
John.
Remember getTransportInfo has generic output as it cannot know what custom headers have been added at runtime. You need to define your own signature In order to reference these custom headers at design time.
To do this map the ‘transport/http/requestHdrs’ output from getTransportInfo to a document type of your own. You can then define the document type with the expected values and be able to reference them in the pipeline.
regards.
John.
Tried this one. Failed.
Well, the custom headers are put in the Postman request part, and then sent. Like this:
It’s the ‘customKey’ part.
You mentioned about ‘add them into input headers’. What do you mean by that, how do I access that in the Designer?
I think there is some confusion, are you trying to do the same call as postman but instead from webMethods ?
If so, click on the flow step pub.client:http in your flow service. Then right click on the ‘headers’ attribute in ‘Service in’ and select ‘insert → string’ and name the string ‘customKey’.
Then either use set value to hard code a value for customKey or map an existing attribute from ‘Pipeline in’.
regards,
John.
@John_Carter4 Uhm, no. I want to make the request from Postman, which hits the service at webMethods, not making the ‘Postman call’ from within webMethods.
Postman Request (with a custom header) > API Gateway Request > webMethods > API Gateway Response > Postman Response.
Have you tried bypassing the API Gateway and calling Integration Server directly. That way if the headers do or do not show up, it will allow you to determine where the problem is i.e. if they show up you know that the issue is in the API Gateway.
Perhaps you have an API policy that is actively clearing out the headers.
regards
John.
@John_Carter4 Tried calling directly to Integration Server. Still didn’t work.
H’mm strange,
I made the following call to my server
curl “http://localhost:5555/rad/jc.api:greeting/hello/John”
-H ‘custom-header: POOOOOOOOP’
-H ‘Accept: application/json’ \
and saw it clearly in the pipeline (see below), could you try making the call via curl as I have ?
This would then remove any configuration issues in postman from the equation.
2022-01-11 09:53:41 CET [ISP.0090.0001C] (tid=117) --- START tracePipeline [11/01/2022, 09:53] ---
2022-01-11 09:53:41 CET [ISP.0090.0008C] (tid=117) 0 name {java.lang.String} = 'John'
2022-01-11 09:53:41 CET [ISP.0090.0008C] (tid=117) 0 transport {com.wm.util.Values} =>
2022-01-11 09:53:41 CET [ISP.0090.0008C] (tid=117) 1 protocol {java.lang.String} = 'http'
2022-01-11 09:53:41 CET [ISP.0090.0008C] (tid=117) 1 subprotocol {java.lang.String} = 'HTTP'
2022-01-11 09:53:41 CET [ISP.0090.0008C] (tid=117) 1 http {com.wm.util.Values} =>
2022-01-11 09:53:41 CET [ISP.0090.0008C] (tid=117) 2 requestUrl {java.lang.String} = '/rad/jc.api:greeting/hello/John'
2022-01-11 09:53:41 CET [ISP.0090.0008C] (tid=117) 2 method {java.lang.String} = 'GET'
2022-01-11 09:53:41 CET [ISP.0090.0008C] (tid=117) 2 requestHdrs {com.wm.util.Values} =>
2022-01-11 09:53:41 CET [ISP.0090.0008C] (tid=117) 3 custom-header {java.lang.String} = 'POOOOOOOOP'
2022-01-11 09:53:41 CET [ISP.0090.0008C] (tid=117) 3 Accept {java.lang.String} = 'application/json'
2022-01-11 09:53:41 CET [ISP.0090.0008C] (tid=117) 3 Cookie {java.lang.String} = 'ATGID=Anonymous'
2022-01-11 09:53:41 CET [ISP.0090.0008C] (tid=117) 3 Host {java.lang.String} = 'localhost:5555'
2022-01-11 09:53:41 CET [ISP.0090.0008C] (tid=117) 3 Connection {java.lang.String} = 'close'
2022-01-11 09:53:41 CET [ISP.0090.0008C] (tid=117) 3 User-Agent {java.lang.String} = 'Paw/3.3.2 (Macintosh; OS X/12.0.1) GCDHTTPRequest'
2022-01-11 09:53:41 CET [ISP.0090.0008C] (tid=117) 2 ipInfo {com.wm.util.Values} =>
2022-01-11 09:53:41 CET [ISP.0090.0008C] (tid=117) 3 localIp {java.lang.String} = '127.0.0.1'
2022-01-11 09:53:41 CET [ISP.0090.0008C] (tid=117) 3 localPort {java.lang.String} = '5555'
2022-01-11 09:53:41 CET [ISP.0090.0008C] (tid=117) 3 remoteIp {java.lang.String} = '127.0.0.1'
2022-01-11 09:53:41 CET [ISP.0090.0008C] (tid=117) 3 remotePort {java.lang.String} = '55765'
2022-01-11 09:53:41 CET [ISP.0090.0002C] (tid=117) --- END tracePipeline ---
@John_Carter4 On second thought, you’re right, the custom header did appear in tracePipeline. Still I have no idea on how to bring that into the designer. Can you help from that?
You need to map the the output from getTransportInfo as such
The resulting document can be either a typed document, in which case you would define it with your custom-header as an attribute in the type or you can do it arbitrarily by adding the customer attribute in pipeline directly like this (right click on header in ‘pipeline in’ and select insert → string)
I would recommend using a branch to check that it exists first, so you don’t get any errors in the case where the header is not provided e.g.
good luck,
John.
1 Like
@John_Carter4 This one I already got (about x-forwarded-for). But the one I have questions for is if I want to bring in the custom-header part. Because that doesn’t appear in the getTransportInfo, even if I put it on in the one that makes the request (Postman). It appears in tracePipeline, but not in getTransportInfo.
no it won’t appear, nor does x-forwarded-for (that’s just a pre-existing example I had) for that matter.
You have to add it explicitly in the map step as I indicated by right clicking on the headers document and selecting insert → string. Then give it the name of your custom header.
You will then map it to an attribute in your pipeline so that you can reference it easily afterwards.
Remember at design time the defaults cannot know what will happen at runtime unless you explicitly define. That’s why I also recommended the branch, because you can make the header mandatory and therefore need to manage the case where it is not provided.
regards,
John.
@John_Carter4 When I did use Branch, it always defaulted to Null. See, it appears in the tracePipeline on the MSR logs, but it doesn’t appear in the RequestHdrs part of the Transport. Therefore, it doesn’t appear in the designer and even if you map the attribute manually, that one variable won’t be mapped. Here are screenshots to prove that these do not get into
First off, the custom header I sent in Postman in this case is named custom-key.
As you can see, they appear in the Pipeline and MSR log
But, when I debug my designer and do getTransportInfo… this is what appears:
As you can see, custom-key is nowhere in sight.
(Or perhaps I should switch around: Trace Pipeline and then Get Transport Info? Admittedly, when I do the test, I run GetTransportInfo first.)
You cannot debug a service with getTransportInfo, because it will get the transport info of your debugger not the original call (restorePipeline does not work with anything other than the already parsed pipeline).
If you want to debug, you will need to add an explicit savePipeline to your code AFTER the restorePipeline step. Run the service from your external client.
After to debug, swap the savePipeline for a restorePipeline and step through the code, the output of the original getTransportInfo will be restored and you will then see all your original custom headers.
regards,
John.
Can you maybe provide screenshots on how to do that save/restore pipeline step by step? As a rule, my Integration Server is located at a remote part (probably with Linux/Ubuntu OS) separate from my Designer (which is using Windows 10 OS). I’ve seen such similar save/restore pipeline method, but I’m a little confused on how it works.
This is the initial state i.e. run this with your external client.
If you want to then debug the service, disabled the first two lines and enable the restorePipeline step like so
Don’t forget to set the name of file to be the same for both save and restore steps
John.
1 Like
Hi,
just one small addition:
it is not neccessary to disable the restorePipelineFromFile in the first screen shot, it can remain enabled and will reread the file written in the previous savePipelineToFile step.
You can collect the getTransportInfo and savePipelineToFile steps in a BRANCH controlled sequence checking a variable if you are running in regular mode (execute them) or in debug mode (skip them).
restorePipelineToFile will then read the current file in regular mode or the older file from older run in debug mode.
Regards,
Holger