Data connections and moving between servers

[Elaine]

Hi friends,

We have forms that each have three data connections on them so that we
can implement back-end search. Currently, the data connections have a
hard-coded url in the WSDL definition that points to our dev server.

We will be migrating these forms to QA and eventually production, and
the WSDL url's will be different (different server names). That means
we will have to edit each form and modify the url to point to QA, and
then do the same thing for prod.

Is there a better way to handle this so that we don't have to modify
each form and change the url?

Thanks,
Elaine

[Mike Weiland]

Here's what I do to handle this, in my situation it's a little different since I mainly deal with Flex applications in workspace and haven't had to come up with a similar scenario for PDF based forms. But this might get your creative juices going. Basically in my process I set a variable for the server to use as the web service server. This variable then gets passed into my flex form when it starts. This way I don't have to recompile for each environment. Granted I have to change a variable in the process after deploying the process to each environment. Something like that should work in a pure PDF scenario.

Mike

[Amal Elaine]

Thanks Mike, but in the data connections palette in designer, you have to enter the url address - which is hard coded - not sure if there is a way to use a variable in this case or not. 

--E

[Armaghan]

Hi Elaine,

Unfortunately there isn't another way. You either have to do it using
Designer or by using a text editor to modify the XDP's XML.

Armaghan.

On May 13, 9:01 am, Amal Elaine <amalela...@gmail.com> wrote:
> Thanks Mike, but in the data connections palette in designer, you have to
> enter the url address - which is hard coded - not sure if there is a way to
> use a variable in this case or not.
>
> --E
>

[Amal Elaine]

Oh, Armaghan, that's not what I wanted to hear.  Hopefully ES2 might offer enhancements?  (Matt?)

Elaine

[Angie Okamoto]

Lee Sutton has an old post about this with a sample file to go with it:
http://blogs.adobe.com/livecycle/2007/12/changing_a_webservice_definiti.html
Angie

--
Angie Okamoto

[Armaghan]

This is a great sample. I wasn't aware of this...but its good to know
now.

I have a question still, how will this change the server address
dynamically ?

Most of the forms don't have visible areas to modify the data
connections when its in production or dev.
Unless we add debug flags and code, we would still need to use
Designer to open, edit and change the WSDL address.

Armaghan.

On May 13, 9:53 am, Angie Okamoto <angie.okam...@gmail.com> wrote:
> Lee Sutton has an old post about this with a sample file to go with it:http://blogs.adobe.com/livecycle/2007/12/changing_a_webservice_defini...

> Angie
>
>
>
> On Wed, May 13, 2009 at 8:20 AM, Amal Elaine <amalela...@gmail.com> wrote:
> > Oh, Armaghan, that's not what I wanted to hear.  Hopefully ES2 might offer
> > enhancements?  (Matt?)
>
> > Elaine
>

> > On Wed, May 13, 2009 at 9:10 AM, Armaghan <armaghan.chaudh...@gmail.com>

[Angie Okamoto]

You could put these fields in all of the necessary forms, and make them hidden.
Then the process could contain a variable that is passed to the form data.
The only values that would have to be changed would be the variables
in development vs production.

Angie

--
Angie Okamoto

[Armaghan]

Youre right we can use the approach you mentioned or if you have a
LiveCycle Server, you can always make a web service call during the
rendering process (Render Service) and populate the form with the
resulting data.

But for stand alone forms which are not tied up with LiveCycle Server,
how would you change the data connection dynamically ?

Armaghan.

[Angie Okamoto]

Unfortunately for stand alone forms, I don't know of an easy solution.
As you previously mentioned using a text editor for find/replace works well.
Angie

--
Angie Okamoto

[Duane Nickull]

My recommendation would be to migrate to a pure 3 tier architecture if
possible. Use LC ES's power to aggregate all the date into one place
so you only have one data connection from the form back to one
instance of LC ES and use SPI's to connect to the other systems. The
caveat is of course that there may be good reason why you cannot do
this but I believe it warrants a look.

Duane

[Amal Elaine]

Thanks Duane,

 

Well, ideally I would like to see one be able to put those data connections into a fragment.  Then the fragment could be placed on every form that needs it.  Right now my search fragment has the data connections, but when the fragment is added to the form those connections have to be re-established.  That's a lot of re-work for different environments...

--
Amal Elaine Photography
http://www.pbase.com/amal007

[Duane Nickull]

The problem you describe below is the main use case for many Adobe server products like Livecycle ds and BlazeDS.  Asking the client to establish and control too may connections and operations on incoming data can lead to slow, sluggish and sometimes errant behavior should one of many servers go down.  The middle tier sits as a proxy and can serve up the last good batches of data on demand, but in a manner optimized for each client (Flash, Acrobat, Reader, HTML, JSP etc.).  On the back end, it can manage the heavy duty lifting and data pulls.

Is it possible you can use LC ES to aggregate all the data and functionality (searches, filters) you require from the client then only establish one connection to LC ES?  If this works, making one fragment like you describe might be the best approach.

Guess you cannot share the specifics though?

;-)

Duane

--
Sr. Technical Evangelist – Adobe Systems
Chair – OASIS SOA RM Technical Committee
Manager – Adobe LiveCycle ES Developers List
Blog: http://technoracle.blogspot.com
Twitter: duanechaos
TV Show: http://www.duanesworldtv.org
Band: http://www.myspace.com/22ndcentury

[Amal Elaine]

Thanks Duane,

I can share the specifics, not a problem there, but your comments have me rethinking my approach.  You know, for each form to make a back-end connection in order to complete a search may be overkill.  I think I will hold on this until we have an adobe resource in house so we can further address an efficient solution.  I continue to suffer from "I don't know what I don't know"  ;-)

Elaine

[billy]

Out of curiosity is your webservice provided by the LC server? We were
having a similar so we dynamically created the webservice connection,
and called the webservice and the result through the script so that
there was no need for binding and using hidden fields. We used the
event.target.URL function to grab the address of the server that the
form is being used on when opened in workspace. Then you'd just do
some string manipulation to grab the first few characters of the
string to get the server name, append your webservice to the end of
the string. The only problem we had with this is that if i went ahead
used pdf preview in designer, it would give me all these msgs saying
that it was trying to connect to my local computer. So we created a
form variable to hold the event.target.URL and if it doesn't start
with "http" it means the form is being called from a local machine
(rather than workspace), and thus an address is hardcoded.
And additional benefit is that you only need to call event.target.url,
so if you're testing through preview pdf, you only get the message
that its trying to connect to your machine once.

function GetWebservice()
{
if(ServerUrl.value!=null && ServerUrl.value.substring(0,4)=="http")
{
//Server Previously Found;
return ServerUrl.value;
}

var server = event.target.URL;
if(server.substring(0,7)!="http://")
server = "http://serverName:8080/workspace/";

server = server.substring(0,server.indexOf("/",8));

ServerUrl.value = server;

return server;
}

Then you can use that url to append your webservice address;

var myUrl = GetWebservice() + "/soap/services/myWebService?wsdl";
var connection = Net.SOAP.connect(myUrl);

var result = connection.webServiceMethod({"param1": value1, "param2":
value2});


Hope that helped and wasn't too unclear :)

Billy

On May 14, 7:58 am, Amal Elaine <amalela...@gmail.com> wrote:
> Thanks Duane,
>
> I can share the specifics, not a problem there, but your comments have me
> rethinking my approach.  You know, for each form to make a back-end
> connection in order to complete a search may be overkill.  I think I will
> hold on this until we have an adobe resource in house so we can further
> address an efficient solution.  I continue to suffer from "I don't know what
> I don't know"  ;-)
>
> Elaine
>

[Amal Elaine]

Wow, This might be exactly what I am looking for.  Will this also remove the need to add the data connection(s) to each form?   Or do they still need to be there?  Thanks for this information, Billy, I will try it out!

Elaine

[billy]

Well, you will still need this on every form, but you can place the
code into a script fragment to easily add into your forms.

On May 14, 1:21 pm, Amal Elaine <amalela...@gmail.com> wrote:
> Wow, This might be exactly what I am looking for.  Will this also remove the
> need to add the data connection(s) to each form?   Or do they still need to
> be there?  Thanks for this information, Billy, I will try it out!
>
> Elaine
>

[Amal Elaine]

No, I think I mean the data connections ... New Data Connection, enter the WSDL name, enter the url of the WSDL... in the data connection palette in designer...  I get the impression that since you're calling everything programmatically you might not need to set up a data connection?  Also, how do you bind the results back to fields on the form?

Hope I'm not all over the place, thanks very much,
E

[billy]

Ah gotcha. No, you won't have to go through the process, and you won't
have to do any binding either because the vaue returned from the
webservice will be assigned into a variable rather than directly to
the rawValue of a field. I'll upload a quick example called
CurrencyConversion.pdf if you want to check out what i'm talking
about.


Billy

[billy]

K, its uploaded, and i just wanted to correct one thing i said. You
don't necessarily have to assign it to a variable, you can assign it
straight into the rawValue of the field you're calling it from. You
just might want to put it into a variable first in case you want to
manipulate the value in any way.

Billy

[bookieb]

Hi Elaine,

our solution is as follows:

Say your data connection is to bring back, for example shipping rates,
so we can put the correct rate on our LC form.

The test LC server should look to the the target URL for the Test
shipping rates service, e.g.:
http://testserver.example.com/shipping_rates?wsdl

And likewise, rhe target URL for the Production shipping rates service
is:
http://prodserver.example.com/shipping_rates?wsdl

So, decide on a hostname that describes the service, e.g.
"shippingrates.example.com".

Hardcode the URL of the dataconnection at:
http://shippingrates.example.com/shipping_rates?wsdl

In the hosts file on the Test LC server, put in an entry like:
192.168.1.200 shippingrates.example.com
...where the IP address is the IP address of testserver.example.com

So, on the Test LC server, when the dataconnection looks for
shippingrates.example.com, that resolves to testserver.example.com -
the Test LC server looks at the Test "shipping rates" server.

Conversely, in the hosts file on the Production LC server, put in an
entry like:
192.168.1.201 shippingrates.example.com
...where this time the IP address is the IP address of
prodserver.example.com

The production LC server looks for shippingrates.example.com, that
resolves to prodserver.example.com - the Production LC server looks at
the Production "shipping rates" server.

For this to work, you need a fair degree of consistency in the URLs of
your "shipping rate" web services.
If, for example the test webservice is at:
http://testserver.example.com/shipping_rates?wsdl
...but the production webservice is at:
http://testserver.example.com/whatever/shipping_rates?wsdl
...then this method won't work.

However, we use this method accross Development, Test, UAT, Training
and Production server sets, and on environments other than LC (e.g.
WAS, Domino, Oracle Apps etc.) and it works fine as long as you are
organised and consistent in locating your web services.

hth,

bookieb.

[Amal Elaine]

Awesome and totally delicious.  So I have three super-cool answers on how to do this, (thank you Duane, Billy and Bookieb)!!!

Thanks very much!

--