ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » IB 10.0.0.4 REST API - missing query parameters in LocalEnv

Post new topic  Reply to topic
 IB 10.0.0.4 REST API - missing query parameters in LocalEnv « View previous topic :: View next topic » 
Author Message
Gralgrathor
PostPosted: Wed May 18, 2016 8:20 am    Post subject: IB 10.0.0.4 REST API - missing query parameters in LocalEnv Reply with quote

Master

Joined: 23 Jul 2009
Posts: 297

Hi!

This is going to be a bit lengthy, with all the code, but here goes.

I've created a YAML with the following operation:
Code:
    /message/id:
        get:
            operationId: findMessageIds
            description: get a collection of message Ids corresponding to search parameters
               
            parameters:
                - name: t1
                  in: query
                  description: start time
                  required: false
                  type: string
                - name: t2
                  in: query
                  description: end time
                  required: false
                  type: string
                - name: dest
                  in: query
                  description: destination url
                  required: false
                  type: string
                - name: iface
                  in: query
                  description: interface id
                  required: false
                  type: string

            responses:
                200:
                    description: An array of message Ids
                    schema:
                        type: array
                        items:
                            $ref: '#/definitions/MessageId'
                default:
                    description: Unexpected error
                    schema:
                        $ref: '#/definitions/Error'

Corresponding JSON:
Code:
        "/message/id": {
            "get": {
                "operationId": "findMessageIds",
                "description": "get a collection of message Ids corresponding to search parameters",
                "parameters": [
                    {
                        "name": "t1",
                        "in": "query",
                        "description": "start time",
                        "required": false,
                        "type": "string"
                    },
                    {
                        "name": "t2",
                        "in": "query",
                        "description": "end time",
                        "required": false,
                        "type": "string"
                    },
                    {
                        "name": "dest",
                        "in": "query",
                        "description": "destination url",
                        "required": false,
                        "type": "string"
                    },
                    {
                        "name": "iface",
                        "in": "query",
                        "description": "interface id",
                        "required": false,
                        "type": "string"
                    }
                ],
                "responses": {
                    "200": {
                        "description": "An array of message Ids",
                        "schema": {
                            "type": "array",
                            "items": {
                                "$ref": "#/definitions/MessageId"
                            }
                        }
                    },
                    "default": {
                        "description": "Unexpected error",
                        "schema": {
                            "$ref": "#/definitions/Error"
                        }
                    }
                }
            }

Now I open up the Toolkit and generate a REST API from this, and the first thing I notice is that the API editor lists the parameters for this operation in the wrong order: t2, iface, t1, dest.

Since I don't really care about the order I go ahead, write some subflows, and then start debugging. To my surprise I see that I'm not getting all the expected parameters in the REST portion of my LocalEnvironment:
Code:
WMQI_LocalEnvironment
   Destination
         HTTP
               RequestIdentifier:BLOB:[B@2f9cc5e0
         RouterList
   HTTP
         Input
               QueryString
                     dest:CHARACTER:http://local
                     t2:CHARACTER:2016-05-18 12:24
                     t1:CHARACTER:2016-05-18 12:22
   REST
         Input
               Method:CHARACTER:GET
               Operation:CHARACTER:findMessageIds
               Path:CHARACTER:/esb/backup/message/id
               URI:CHARACTER:http://localhost:7802/esb/backup/message/id
               Parameters
                     t2:CHARACTER:2016-05-18 12:24

Two of the three parameters submitted are missing, even though they're listed in the HTTP secion of the LocalEnv.

So I add the fourth parameter to the request, and now I get this:
Code:
WMQI_LocalEnvironment
   Destination
         HTTP
               RequestIdentifier:BLOB:[B@2f9cc5e0
         RouterList
   HTTP
         Input
               QueryString
                     dest:CHARACTER:http://local
                     t2:CHARACTER:2016-05-18 12:24
                     iface:CHARACTER:SOME
                     t1:CHARACTER:2016-05-18 12:22
   REST
         Input
               Method:CHARACTER:GET
               Operation:CHARACTER:findMessageIds
               Path:CHARACTER:/esb/backup/message/id
               URI:CHARACTER:http://localhost:7802/esb/backup/message/id
               Parameters
                     dest:CHARACTER:http://local
                     iface:CHARACTER:SOME
                     t1:CHARACTER:2016-05-18 12:22
                     t2:CHARACTER:2016-05-18 12:24

And suddenly they're all there. Only I notice that they're in a different order, both different from the listing in the API editor, and different from the order in the request. The same thing happens whether the parameters are required or not. Again, I don't mind the different order so much - it's curious, that's all - but I am puzzled as to why parameters should go missing in the REST section of the LocalEnv.

Am I missing something? Am I growing senile? Is this material for a PMR?

Thanks in advance for any reaction!

Gr,

Gr.
_________________
A measure of wheat for a penny, and three measures of barley for a penny; and see thou hurt not the oil and the wine.
Back to top
View user's profile Send private message Send e-mail
mqjeff
PostPosted: Wed May 18, 2016 8:27 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

... uhh... what does a usertrace show... ?
_________________
chmod -R ugo-wx /
Back to top
View user's profile Send private message
Gralgrathor
PostPosted: Wed May 18, 2016 11:54 pm    Post subject: Reply with quote

Master

Joined: 23 Jul 2009
Posts: 297

mqjeff wrote:
what does a usertrace show?

Nothing much. The REST and HTTP sections of the LocalEnv are populated when the JSON parser on the HTTPInput node is applied to the input.

A system trace on the EG shows the following lines while populating the REST section:
Code:
2016-05-18 18:43:06.115418     9972   } ImbRestApplication::extractQueryParameter 5129a269-acae-4dbc-bd88-a45a52bd53bf Application , BackupAPI
2016-05-18 18:43:06.115419     9972   ImbRestApplication::beforePropagateOutput 5129a269-acae-4dbc-bd88-a45a52bd53bf Application 'Looking for parameter' , 'dest', BackupAPI
2016-05-18 18:43:06.115420     9972   { ImbRestApplication::extractQueryParameter 5129a269-acae-4dbc-bd88-a45a52bd53bf Application , '[ImbOwnedLogSource::addLogInserts called - subclass failed to implement this]', false, BackupAPI
2016-05-18 18:43:06.115422     9972     { ImbMessage::ReadCursor::isValid gen/BackupAPI#FCMComposite_1_1 ComIbmWSInputNode , gen.BackupAPI.HTTP Input
2016-05-18 18:43:06.115423     9972     } ImbMessage::ReadCursor::isValid gen/BackupAPI#FCMComposite_1_1 ComIbmWSInputNode , false, gen.BackupAPI.HTTP Input
2016-05-18 18:43:06.115425     9972     ImbRestApplication::extractQueryParameter 5129a269-acae-4dbc-bd88-a45a52bd53bf Application 'The REST API operation requires a query parameter that is not set' , 'findMessageIds', 'dest', BackupAPI


Which is peculiar, because just a few lines above, while populating the HTTP section of LocalEnv, the same thread says this:
Code:
2016-05-18 18:43:06.115068     9972     { ImbURLEncode::decode
2016-05-18 18:43:06.115071     9972     } ImbURLEncode::decode , 'dest'
2016-05-18 18:43:06.115072     9972     { ImbMessage::WriteCursor::createLastChild gen/BackupAPI#FCMComposite_1_1 ComIbmWSInputNode , 'dest', gen.BackupAPI.HTTP Input
2016-05-18 18:43:06.115074     9972       { ImbSyntaxElementPool::createElement gen/BackupAPI#FCMComposite_1_1 ComIbmWSInputNode , (*ptr)465eb540, gen.BackupAPI.HTTP Input
2016-05-18 18:43:06.115075     9972       } ImbSyntaxElementPool::createElement gen/BackupAPI#FCMComposite_1_1 ComIbmWSInputNode , (*ptr)465eb540, (*ptr)46049010, 8, gen.BackupAPI.HTTP Input
2016-05-18 18:43:06.115077     9972     } ImbMessage::WriteCursor::createLastChild gen/BackupAPI#FCMComposite_1_1 ComIbmWSInputNode , gen.BackupAPI.HTTP Input
2016-05-18 18:43:06.115078     9972     { ImbMessage::ReadCursor::moveToLastChild gen/BackupAPI#FCMComposite_1_1 ComIbmWSInputNode , gen.BackupAPI.HTTP Input
2016-05-18 18:43:06.115080     9972     } ImbMessage::ReadCursor::moveToLastChild gen/BackupAPI#FCMComposite_1_1 ComIbmWSInputNode , gen.BackupAPI.HTTP Input
2016-05-18 18:43:06.115081     9972     { ImbMessage::WriteCursor::setValue gen/BackupAPI#FCMComposite_1_1 ComIbmWSInputNode , gen.BackupAPI.HTTP Input
2016-05-18 18:43:06.115083     9972     } ImbMessage::WriteCursor::setValue gen/BackupAPI#FCMComposite_1_1 ComIbmWSInputNode , gen.BackupAPI.HTTP Input
2016-05-18 18:43:06.115085     9972     { ImbURLEncode::decode
2016-05-18 18:43:06.115086     9972       { ImbURLEncode::decodePercentEncodedPair
2016-05-18 18:43:06.115087     9972         { ImbURLEncode::getHexCharacterValue
2016-05-18 18:43:06.115088     9972         } ImbURLEncode::getHexCharacterValue , 3
2016-05-18 18:43:06.115089     9972         { ImbURLEncode::getHexCharacterValue
2016-05-18 18:43:06.115090     9972         } ImbURLEncode::getHexCharacterValue , 10
2016-05-18 18:43:06.115091     9972       } ImbURLEncode::decodePercentEncodedPair , 58
2016-05-18 18:43:06.115092     9972       { ImbURLEncode::decodePercentEncodedPair
2016-05-18 18:43:06.115093     9972         { ImbURLEncode::getHexCharacterValue
2016-05-18 18:43:06.115093     9972         } ImbURLEncode::getHexCharacterValue , 2
2016-05-18 18:43:06.115094     9972         { ImbURLEncode::getHexCharacterValue
2016-05-18 18:43:06.115095     9972         } ImbURLEncode::getHexCharacterValue , 15
2016-05-18 18:43:06.115096     9972       } ImbURLEncode::decodePercentEncodedPair , 47
2016-05-18 18:43:06.115097     9972       { ImbURLEncode::decodePercentEncodedPair
2016-05-18 18:43:06.115098     9972         { ImbURLEncode::getHexCharacterValue
2016-05-18 18:43:06.115098     9972         } ImbURLEncode::getHexCharacterValue , 2
2016-05-18 18:43:06.115100     9972         { ImbURLEncode::getHexCharacterValue
2016-05-18 18:43:06.115101     9972         } ImbURLEncode::getHexCharacterValue , 15
2016-05-18 18:43:06.115102     9972       } ImbURLEncode::decodePercentEncodedPair , 47
2016-05-18 18:43:06.115103     9972     } ImbURLEncode::decode , 'http://local'

Which, by happy coincidence, is exactly the value I added to the request.

So I'm thinking PMR. It'd be nice if I could actually submit one.

O, and this is funny too: missing required parameters are given the value 'NULL', so that
Code:
COALESCE(InputLocalEnvironment.REST.Input.Parameters.parameter, '')
Yields 'NULL' rather than ''.
_________________
A measure of wheat for a penny, and three measures of barley for a penny; and see thou hurt not the oil and the wine.
Back to top
View user's profile Send private message Send e-mail
timber
PostPosted: Thu May 19, 2016 3:59 am    Post subject: Reply with quote

Grand Master

Joined: 25 Aug 2015
Posts: 1292

I tried this on 10.0.0.3 ( Windows ).

I added a basePath of '/messageIds/v1' to your Swagger, created a REST API from it and tested it using SoapUI. The order in which the parameters are listed seems to vary, but they were all there for me in both the HTTP and the REST subtree.

Can you post the REST query that you are using to invoke this API? The error message 'The REST API operation requires a query parameter that is not set' seems to imply that you did not supply all of the parameters.
Back to top
View user's profile Send private message
Gralgrathor
PostPosted: Thu May 19, 2016 5:25 am    Post subject: Reply with quote

Master

Joined: 23 Jul 2009
Posts: 297

timber wrote:
Can you post the REST query that you are using to invoke this API?

Definition calls for t1, t2, dest and iface, none of these required.

Case 1: Only dest and iface given:
Code:
GET http://localhost:7802/esb/backup/message/id?dest=http%3A%2F%2Flocal&iface=The HTTP/1.1
Accept-Encoding: gzip,deflate

Produces
Code:
LocalEnvironment
   Destination
         HTTP
               RequestIdentifier:BLOB:[B@d262afe
         RouterList
               DestinationData
                     labelName:CHARACTER:findMessageIds
   HTTP
         Input
               QueryString
                     dest:CHARACTER:http://local
                     iface:CHARACTER:The
   REST
         Input
               Method:CHARACTER:GET
               Operation:CHARACTER:findMessageIds
               Path:CHARACTER:/esb/backup/message/id
               URI:CHARACTER:http://localhost:7802/esb/backup/message/id
               Parameters


Case 2: t1, t2, dest and iface given:
Code:
GET http://localhost:7802/esb/backup/message/id?t1=2016-05-19%2000&t2=2016-05-19%2023&dest=http%3A%2F%2Flocal&iface=The HTTP/1.1
Accept-Encoding: gzip,deflate
Host: localhost:7802
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.1.1 (java 1.5)


Code:
LocalEnvironment
   Destination
         HTTP
               RequestIdentifier:BLOB:[B@b49f45ed
         RouterList
               DestinationData
                     labelName:CHARACTER:findMessageIds
   HTTP
         Input
               QueryString
                     t1:CHARACTER:2016-05-19 00
                     t2:CHARACTER:2016-05-19 23
                     dest:CHARACTER:http://local
                     iface:CHARACTER:The
   REST
         Input
               Method:CHARACTER:GET
               Operation:CHARACTER:findMessageIds
               Path:CHARACTER:/esb/backup/message/id
               URI:CHARACTER:http://localhost:7802/esb/backup/message/id
               Parameters
                     dest:CHARACTER:http://local
                     iface:CHARACTER:The
                     t1:CHARACTER:2016-05-19 00
                     t2:CHARACTER:2016-05-19 23

Case 3: t1, t2 given:
Code:
GET http://localhost:7802/esb/backup/message/id?t1=2016-05-19%2000&t2=2016-05-19%2023 HTTP/1.1
Accept-Encoding: gzip,deflate
Host: localhost:7802
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.1.1 (java 1.5)

Produces:
Code:
LocalEnvironment
   Destination
         HTTP
               RequestIdentifier:BLOB:[B@ef4ef7b2
         RouterList
               DestinationData
                     labelName:CHARACTER:findMessageIds
   HTTP
         Input
               QueryString
                     t1:CHARACTER:2016-05-19 00
                     t2:CHARACTER:2016-05-19 23
   REST
         Input
               Method:CHARACTER:GET
               Operation:CHARACTER:findMessageIds
               Path:CHARACTER:/esb/backup/message/id
               URI:CHARACTER:http://localhost:7802/esb/backup/message/id
               Parameters
                     t2:CHARACTER:2016-05-19 23


Notice that the HTTP querystring section of the localenvironment does contain all the parameters from the request in each case.
_________________
A measure of wheat for a penny, and three measures of barley for a penny; and see thou hurt not the oil and the wine.
Back to top
View user's profile Send private message Send e-mail
mqjeff
PostPosted: Thu May 19, 2016 5:32 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

Oh, er.

The subject says what version...

Are you using the EG http listener? or the bip listener?
_________________
chmod -R ugo-wx /
Back to top
View user's profile Send private message
Gralgrathor
PostPosted: Thu May 19, 2016 5:53 am    Post subject: Reply with quote

Master

Joined: 23 Jul 2009
Posts: 297

mqjeff wrote:
Are you using the EG http listener?

I don't think the REST API will even work on the BIP listener, so it's configured to use the embedded listener.
_________________
A measure of wheat for a penny, and three measures of barley for a penny; and see thou hurt not the oil and the wine.
Back to top
View user's profile Send private message Send e-mail
timber
PostPosted: Thu May 19, 2016 6:30 am    Post subject: Reply with quote

Grand Master

Joined: 25 Aug 2015
Posts: 1292

Quote:
Definition calls for t1, t2, dest and iface, none of these required.
I agree. I suspect that this is what is happening:
- The 'HTTP' subtree is generic. A REST API uses an HTTP node under the covers, so this subtree gets populated automatically. It contains whatever the HTTP node received. So missing parameters ( whether validly missing or not ) will not appear in this subtree.
- The 'REST' subtree is created by a REST API only. It always contains the full list of parameters. Missing parameters are deliberately given the value NULL to distinguish them from parameters that are present with their value set to "" ( the empty string).

All of the above is no more than an educated guess. Especially the part about the REST subtree, because the Knowledge Center has nothing to say about it.
Back to top
View user's profile Send private message
mqjeff
PostPosted: Thu May 19, 2016 6:37 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

Gralgrathor wrote:
mqjeff wrote:
Are you using the EG http listener?

I don't think the REST API will even work on the BIP listener, so it's configured to use the embedded listener.


Ok. Well. If you're really feeling brave, you can a) enable a service trace, b) modify the internal config of the eg listener (... I've forgotten where that's kept these days... )
_________________
chmod -R ugo-wx /
Back to top
View user's profile Send private message
Gralgrathor
PostPosted: Thu May 19, 2016 6:45 am    Post subject: Reply with quote

Master

Joined: 23 Jul 2009
Posts: 297

timber wrote:
The 'REST' subtree is created by a REST API only. It always contains the full list of parameters. Missing parameters are deliberately given the value NULL to distinguish them from parameters that are present with their value set to ""

If it were just the order or the 'NULL' (in stead of NULL) values I would be totally cool with that. Icelike, even.

But the REST API randomly vanishing parameters, whether or not given, whether or not required, that's a bit inconvenient, to say the least.

So for now I've taken to using LocalEnvironment.HTTP rather than LocalEnvironment.REST as a source for parameters.
_________________
A measure of wheat for a penny, and three measures of barley for a penny; and see thou hurt not the oil and the wine.
Back to top
View user's profile Send private message Send e-mail
timber
PostPosted: Thu May 19, 2016 6:53 am    Post subject: Reply with quote

Grand Master

Joined: 25 Aug 2015
Posts: 1292

Yes - the missing parameters in the REST subtree are hard to explain.
I wonder whether @stoney is watching this thread...
Back to top
View user's profile Send private message
stoney
PostPosted: Thu May 19, 2016 9:05 am    Post subject: Reply with quote

Centurion

Joined: 03 Apr 2013
Posts: 140

I'm always watching

I've reproduced the problem - there's definitely a defect here - apologies!
I can build and ship you an interim fix to resolve the problem if you can raise a PMR. No PMR, no interim fix.
If you do raise a PMR, then ask for it to be sent directly to L3 for the attention of SS1 and reference this thread.
If you don't or can't raise a PMR, then it's too late for the imminent 10.0.0.5 fix pack, but it should make it into the fix pack after that.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » IB 10.0.0.4 REST API - missing query parameters in LocalEnv
Jump to:  



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.