Button Script executing in Workspace loses context after web service call in Non-Reader extended form

[Mark_Lindberg]

Greetings:

My environment uses Workspace, and non-reader extended forms.

We have data connection access to WSDLs to return data for Dropdowns - (This is working).

The issue we have encountered, is when we have a script running (button or otherwise) that has JavaScript code to execute after the service call.

Once the call fires, and the data returns - all script context is lost.

"<object> is not defined" errors occur when trying to reference any object in the form or the data returned.

A scenario would be a button click event that:

1. Moves form field data to the WSDL Request data area.

2. Invoke the WSDL

3. Evaluate result of WSDL call

4. Move data form result are to form fields.

In our experience, after step 2 the code loses the ability to address any part of the form.

We have tried to display out the form's somExpression, and the result is "Undefined".

We have the DataConnection execute set to run on server, and have tried setting the button to run on Client, Server or both.

Once the form reloads in the UI, the form behaves as expected, but steps 3 and 4 above have been lost.

Remerge and Relayout commands do not seem to help the situation.

Our desired application is trying to use a single dataconnection multiple times to populate 10 different logical areas on the form.

Without being able to retain context for the round trip, it is very difficult to properly trap errors and process results.

Can anyone offer advice on how to have the script not lose context, or wait until the form is ready to continue?

Thank You

Mark

[_Nith_]

Hi, Let me share my experience..

If you use DataConnection to a WSDL, you must reader-extend the form.

This rule is exceptional for the Designer; which means while designing the form you need not reader-extend(but you can see reults in preview pdf tab).

But when you deploy your form in the workspace, the form should get reader extended in-order to communicate to a web service.

Or post a sample form, i will have a look at it.

Nith

[Mark_Lindberg]

Hi $Nith$:

Just to clarify - We currently do have Non extended xdp forms calling WSDL data connections.

This does work with Service Pack 2 and the ES Update 1 renderers.

The difficulty is that in our current path to success - the form scripts cannot retain addressability across the service call.

This forces the use of hidden indicator fields to tell the form what is was trying to do before the call, and how to process after the call.

It is our hope that there is a solution that will allow the script to retain control, and also have access to the som.

At present, when the script regains control after the call, all addressability to the som is gone.  It seems to return once the UI is refreshed.

Thanks Again

Mark

[_Nith_]

1. Is your web service is of Async type?

2. Are you trying to address the web service results immediatelly after calling the web service?

In this case you might encounter few issues. This is because your web service produces asynchronous results and may not be available to script until the web service is completelly executed. However your script won't wait for the web service to complete.

Thanks,

Nith

[Mark_Lindberg]

I believe the web service is syncronous.  I send 3 values, and expect 2 in return.

Thanks

Mark

[_Nith_]

Are you refering the SOAP endpoint, or any third-party web services?

[Mark_Lindberg]

The web service is one I have set up on the Livecycle server.

I am not referring to any other services.

I used Designer to pull in the WSDL to the DataConnection.

[_Nith_]

Okay, now you need to make sure that your web service is synchronous.

This is because if you drag any components such as Execute Script, your web service will behave as asynchronous.

Just make sure that you have dragged only synchronous components into your workflow which was exposed as web service.

Thanks & Regards,

Nith

[Mark_Lindberg]

Thanks for your assistance.

How do you identify synchronous components in a workflow?

Mark

[_Nith_]

The operations of the User, Wait Point, and Execute Script services, as well as gateway elements, cause synchronous branches to behave as asynchronous branches.

Thanks & Regards,

Nith

[Mark_Lindberg]

I will try the process without ExecuteScript - there was one in there.

What about SetValue, LDAPService, or Decision Point?

Thanks Again

Mark

[_Nith_]

Set Value & Decision Points are Synchronous, but I'm not sure about the LDAPService.

Just try to suppress the ExecuteScript component and give it a try.

Thanks & Regards,

Nith

[Mark_Lindberg]

Stripped down version consisting of Decision Point, and Set Value yield the same result.

Based on app.alerts, script seems to wait for data to return, but once control is returned to the script, the form structure is not in a state that is addressable by the script.

An attempt to test a value in a field of the result set generates a "<fieldname> is not defined" error.

[_Nith_]

Could you post your script for a review?

Nith

[Mark_Lindberg]

Here is what I have learned through various conversations.

When a form is presented by WorkSpace and NOT Reader Extended, in essence the complete form will make a round trip to the server and back to get the data.  The server will actually make the web service call and load the data into the form, then return it to the client.

As such, the data is not available to the script that caused the invocation of the data connection (Any code after the execute is useless).

In order to make such a scenario work, either the results of the data connection are bound into displayed fields, and whatever result comes back is OK in terms of the user experience - or - Prior to executing the web service call, indicator fields are set so that when control returns to the form events, the form coding can determine what action was initiated, and complete that action, evaluating the data returned, and setting fields and messages as needed.

In my testing, I was able to place scripts into subform initialize events to detect that a particular data connection had been executed, and to complete the error checking, and data population, as well as resetting the process flag for that connection.

It would be much easier if Reader Extensions were in the environment - as the call to the Web Service would be directly from the client to the service, and control would remain with the button script.

Hope this is helpful.

Mark