| Author |
Message
|
| iib |
 Posted: Wed Apr 27, 2016 6:37 am Post subject: SoapReply Node EndPoint Dinamic |
 |
|
Apprentice
Joined: 26 Jun 2015
Posts: 27
|
| I can please help with this issue; I'm calling a web service from the BPM using SOAPRequest node, the endpoint changes in each environment, how can I change the EndPoint without generating several .bar for environment and without using user-defined property? |
|
| Back to top |
|
 |
| Vitor |
| Posted: Wed Apr 27, 2016 6:52 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Promote the property and override it during your deploy process.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| maurito |
| Posted: Wed Apr 27, 2016 7:53 am Post subject: Re: SoapReply Node EndPoint Dinamic |
|
|
Partisan
Joined: 17 Apr 2014
Posts: 358
|
| iib wrote: |
| I can please help with this issue; I'm calling a web service from the BPM using SOAPRequest node, the endpoint changes in each environment, how can I change the EndPoint without generating several .bar for environment and without using user-defined property? |
You can also use the LocalEnvironment to set the endpoint.
In the compute node you can also query the Broker name ( and a few other Broker defined properties ), and use that to decide what end point to use. |
|
| Back to top |
|
|
| iib |
| Posted: Wed Apr 27, 2016 8:11 am Post subject: |
|
|
Apprentice
Joined: 26 Jun 2015
Posts: 27
|
In the first proposal you have; Set the property by a single .bar file during the deployment process in a different environment example:
Development Environment
<ConfigurableProperty override = "http: // development: 7888 / info.tws" uri = "Flows.Ejemplo # webServiceURL" />
Testing environment
<ConfigurableProperty <ConfigurableProperty override = "http: // test: 7888 / info.tws" uri = "Flows.Ejemplo # webServiceURL" />
Second proposal: Configure LocalEnvironment use to configure the EndPoint.
Already I knew the two options I do not want is to have that degree of uncertainty that the probability of error deployment have. Is there any other option? |
|
| Back to top |
|
|
| joebuckeye |
| Posted: Wed Apr 27, 2016 8:14 am Post subject: |
|
|
Partisan
Joined: 24 Aug 2007
Posts: 364
Location: Columbus, OH
|
We have done this in both methods mentioned.
1) have a properties file that you run against barfileoverrides to create bars for each environment
2) an environmental subflow that looks up the broker and tells you what environment you are in, then the flow will set the URL based on that
Some types are against #1 because they want to see the same "code" in each environment. We have been able to convince them that doing bar file overrides does not touch the code and only configures things.
The disadvantage with #2 is that if your infrastructure changes in any fashion now you have to make a code change to take the new brokers/environments into consideration.
I greatly prefer method #1. If an endpoint needs to change or a new environment spun up all we have to do is create a new bar file override properties file and use it. Much easier to handle than case #2. |
|
| Back to top |
|
|
| maurito |
| Posted: Wed Apr 27, 2016 8:16 am Post subject: |
|
|
Partisan
Joined: 17 Apr 2014
Posts: 358
|
| iib wrote: |
In the first proposal you have; Set the property by a single .bar file during the deployment process in a different environment example:
Development Environment
<ConfigurableProperty override = "http: // development: 7888 / info.tws" uri = "Flows.Ejemplo # webServiceURL" />
Testing environment
<ConfigurableProperty <ConfigurableProperty override = "http: // test: 7888 / info.tws" uri = "Flows.Ejemplo # webServiceURL" />
Second proposal: Configure LocalEnvironment use to configure the EndPoint.
Already I knew the two options I do not want is to have that degree of uncertainty that the probability of error deployment have. Is there any other option? |
1- You don't want to use User defined properties,
2- You don't want to use the first of the suggestions
3- You don't want to use the second of the suggestions.
Why don't you raise an RFE and ask IBM for what you want ?
and can you please explain the "uncertainty that ...etc"
do you mean you don't test your code before deploying ? |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Apr 27, 2016 8:21 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
You could always use an EndpointLookup node.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| maurito |
| Posted: Wed Apr 27, 2016 8:29 am Post subject: |
|
|
Partisan
Joined: 17 Apr 2014
Posts: 358
|
| mqjeff wrote: |
| You could always use an EndpointLookup node. |
Yes, and guess what the answer will be... I already knew that, but we don't want to use and EnpointLooup node |
|
| Back to top |
|
|
| iib |
| Posted: Wed Apr 27, 2016 8:35 am Post subject: |
|
|
Apprentice
Joined: 26 Jun 2015
Posts: 27
|
| To use the Endpoint Lookup would be great, but we have not WSRR therefore will choose one of two options mentioned in the thread. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Apr 27, 2016 8:38 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| maurito wrote: |
| mqjeff wrote: |
| You could always use an EndpointLookup node. |
Yes, and guess what the answer will be... I already knew that, but we don't want to use and EnpointLooup node |
Nope, the answer was what I expected
| iib wrote: |
| To use the Endpoint Lookup would be great, but we have not WSRR |
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
|
|
