| Author |
Message
|
| sibcool |
 Posted: Thu Feb 13, 2014 11:47 am Post subject: SOAPInput node based webservice issue |
 |
|
Novice
Joined: 17 Mar 2008
Posts: 20
|
Webservices flow only running under one execution group on WMB 7.0.0.4. If I try deploy a new ws flow to another execution then I get the Unsupported Method: GET page error when trying to access the wsdl but it works fine under the one execution group. e.g. scenario
ExecutionGroupA
WSFlowA
WSFlowB etc etc
works but,
ExecutionGroupA
WSFlowA
ExecutionGroupB
WSFlowB
WSFlowA works but not B. Probably something simple I'm missing, any ideas? |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Thu Feb 13, 2014 12:05 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Did you check the port for eg B? 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Feb 13, 2014 12:06 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Using the broker level or EG level listeners? If EG level the port numbers will differ.
And you talk about WSDL, which implies SOAPInput, which implies.....? 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| sibcool |
| Posted: Thu Feb 13, 2014 3:07 pm Post subject: |
|
|
Novice
Joined: 17 Mar 2008
Posts: 20
|
Thank you guys. I'm such a lazy reader. Didn't know about the port ranges (karma for being a biztalk developer as well I suppose). All sorted now though, it was the execution group level listener. First tried server:7801 = connection refused but then server:7802 worked after updating the wsdl.
Found the command to check the port on said EG but couldn't get to the unix shell, auto gen'd passwords appear not to have synced correctly thus the trial and error (possibly useless additional info).
Thanx again. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Feb 14, 2014 5:18 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sibcool wrote: |
| Thank you guys. I'm such a lazy reader. Didn't know about the port ranges (karma for being a biztalk developer as well I suppose). All sorted now though, it was the execution group level listener. First tried server:7801 = connection refused but then server:7802 worked after updating the wsdl. |
If you read a bit more, you'll find a section where it talks about how to specify a port rather than sequence dialing to see what port is being used (each EG will have it's own port numbers, so 7801/2 may not work in other environments).
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| sibcool |
| Posted: Fri Feb 14, 2014 10:07 am Post subject: |
|
|
Novice
Joined: 17 Mar 2008
Posts: 20
|
| Ah yes, unfortunately the developer users are restricted from issuing any mqsi* commands in the unix shell. But may have a good reason to have them revise these permissions or something. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Fri Feb 14, 2014 6:27 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
If your site is into WebServices then you might like to get your broker creation process modified so that when you create an Execution Group you setup an HTTP Port for SOAP Traffic at the time of creation. IT will save you a lot of heartache later on especially if as you say, your devs can't run any mqsi* commands.
However you do need to possibly rethink that policy certainly for your DEV and Test environment. That rule stops them from running usertrace and then reading and formatting the log.
I would guess that your admins might get peed off quite quickly if they have to do it for the devs each and every time one needs a trace. Even more so if, is as quite common in many places in order to get the admins to do anything you need to raise a trouble ticket. A usertrace request is very low on their priority pecking order so may take DAYS to get done.
Think about the impact on your development/testing schedules if that were the norm.
Some happy medium where the mqsichangetrace and associated commands can be done by the devs would be ideal. Also consider the mqsilist & mqsireport* commands. i.e. the ones that read broker status/properties.
IMHO, securing an environment so that devs could use these commands would make a nice 'RedPaper' (not just on Z/OS but on all supported environments as well)
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| sibcool |
| Posted: Wed Feb 19, 2014 4:20 am Post subject: |
|
|
Novice
Joined: 17 Mar 2008
Posts: 20
|
| Quote: |
| If your site is into WebServices then you might like to get your broker creation process modified so that when you create an Execution Group you setup an HTTP Port for SOAP Traffic at the time of creation. |
Was wondering about this, definitely will look into it.
Well this will be the first webservice and there may only be 2 or 3 more that ever get developed. Bulk of our webservice integration deployment lives in the world of M$ BizTalk.
yeah, usertraces are a luxury and the kill command (3 - ?many hrs of dev time are wasted on things that loop infinitely), but I fear the battle of having this change. It's not the broker admins per se that are problem but the unix solaris admins - are all unix admins angry people I wonder. It was their policy that brought in the high level of shell security. |
|
| Back to top |
|
|
|
|
