| Author |
Message
|
| gs |
 Posted: Wed Sep 25, 2013 7:21 am Post subject: SOAPRequest URL outside flow/bar file? |
 |
|
Master
Joined: 31 May 2007
Posts: 254
Location: Sweden
|
I'd like to configure the URL outside of the flow and bar file for easier deployment and to minimize errors done by the deployment team.
In the best of worlds I'd like to set the URL as a configurable service and then refer to that from the SOAPRequest node.
Seeing that this is not possible, are there any other options than the following which all are not optimal but in preferable order:
1. Get the configurable service parameters from a Java node
2. Query an external database
3. ESQL hardcode the URL's with an if statement based on Production/QA server
Any other recommendations or comments on the ones above?
Thanks! |
|
| Back to top |
|
 |
| Simbu |
| Posted: Wed Sep 25, 2013 7:34 am Post subject: |
|
|
Master
Joined: 17 Jun 2011
Posts: 289
Location: Tamil Nadu, India
|
| how about using EndpointLookup node to get the url from WSRR |
|
| Back to top |
|
|
| gs |
| Posted: Wed Sep 25, 2013 7:52 am Post subject: |
|
|
Master
Joined: 31 May 2007
Posts: 254
Location: Sweden
|
| Simbu wrote: |
| how about using EndpointLookup node to get the url from WSRR |
Unfortunately the client doesn't use WSRR. Otherwise, that'd been a feasible option. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Wed Sep 25, 2013 8:23 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
You can load GlobalCache with the URL and other parameters as needed. The GlobalCache can be refreshed on-the-fly in case you need to change the URL for some reason. If you don't have version 8, you can create your own cache using the Singleton pattern.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| mapa |
| Posted: Wed Sep 25, 2013 11:50 am Post subject: |
|
|
Master
Joined: 09 Aug 2001
Posts: 257
Location: Malmö, Sweden
|
I would say get your build and deployment process in place instead.
Automating the build and semi-automating the deployment is the way to go instead of creating unnecessary complexity in the broker.
Going for using the global cache if it is just an URL per environment is way overkill for something this simple.
Doing it this way has almost eliminated the production deployment issues that we all too often faced before, it is a game changer to be able to trust your deployments...
In your case I would use mqsiapplybaroverride to override the URL.
I would go for the version of setting an easily identifiable dummy value in the messageflow and then a properties file per target enviroment in the deploy phase.
| Code: |
mqsiapplybaroverride -b <id>.bar -p <id>-env-test.properties
|
The properties file then being as simple as:
| Code: |
SOAP_URI=http://example.org/test/myGreatSOAPService
|
|
|
| Back to top |
|
|
| gs |
| Posted: Thu Sep 26, 2013 3:25 am Post subject: |
|
|
Master
Joined: 31 May 2007
Posts: 254
Location: Sweden
|
| An automated process is something I'd like to see in the future but we're far from that today. Thanks for all input, we'll probably go for separate BAR files where the URL is overridden. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Sep 26, 2013 5:20 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
even if you don't have an "automated" process, it's dead-easy to build a manual process that uses scripts to do the work.
so instead of you having to remember to run mqsipackagebar/mqsicreatebar with all the right options, and then mqsiapplybaroverride with all the right options and then mqsideploy with all the right options, you can put all of the right options into a script file that runs the command.
Then the manual process consists of running the script.
Later, when you automate, the automated process consists of... running the script. |
|
| Back to top |
|
|
| mapa |
| Posted: Thu Sep 26, 2013 5:32 am Post subject: |
|
|
Master
Joined: 09 Aug 2001
Posts: 257
Location: Malmö, Sweden
|
| mqjeff wrote: |
even if you don't have an "automated" process, it's dead-easy to build a manual process that uses scripts to do the work.
so instead of you having to remember to run mqsipackagebar/mqsicreatebar with all the right options, and then mqsiapplybaroverride with all the right options and then mqsideploy with all the right options, you can put all of the right options into a script file that runs the command.
Then the manual process consists of running the script.
Later, when you automate, the automated process consists of... running the script. |
 That is exactly how we did it, started with the scripts on a developer level... |
|
| Back to top |
|
|
| joebuckeye |
| Posted: Thu Sep 26, 2013 7:53 am Post subject: |
|
|
Partisan
Joined: 24 Aug 2007
Posts: 365
Location: Columbus, OH
|
This is what I have started doing during our v7 to v8 migration (yes we are a little slow).
It's so easy once you get the first ant script built to replicate it across other projects. |
|
| Back to top |
|
|
| gs |
| Posted: Thu Oct 17, 2013 10:59 am Post subject: |
|
|
Master
Joined: 31 May 2007
Posts: 254
Location: Sweden
|
| I ended up creating a simple script per project and individual property files / BAR files per environment. The more I thought about it the more it made sense to have separate BAR files. Thanks once again. |
|
| Back to top |
|
|
|
|
