Blog Elements

Half Sized Blog Element (Single Author Style)

Half Sized Blog Element (Multi Author Style)

Calling external web services and displaying data

Users can create external web service calls and display these data in a datagrid in the form. Users can create external web service calls and display these data in a datagrid in the form. NOTE: Other controls can also be connected with a web service call. In that case only the first attribute for the first […]

August 15, 2017/by Konstantinos

Knowledge Base, PowerForms Siverlight, Web Services and Web Posts

Manually Calling Web Services

With PowerForms, users could bind specific controls to existing web services and retrieve values automatically during form initialization or whenever another control that affected the web service call occurred. In version 2.0, a new Button control is introduced, which allows users to manualy call web services, or list queries and apply the retrieved data to […]

August 15, 2017/by Konstantinos

Knowledge Base, PowerForms Siverlight, Web Services and Web Posts

Calling external web services and displaying data

August 15, 2017/by Konstantinos

Knowledge Base, PowerForms Siverlight, Web Services and Web Posts

Manually Calling Web Services

August 15, 2017/by Konstantinos

Full Sized Blog Element (Big Preview Pic)

Knowledge Base, PowerForms Siverlight, Web Services and Web Posts

Calling external web services and displaying data

Users can create external web service calls and display these data in a datagrid in the form.

NOTE: Other controls can also be connected with a web service call. In that case only the first attribute for the first record will be used and if the value is valid for that control it will be displayed properly.

To define a new web service call all of the followng properties must be defined:

A custom Name for referencing the web service call
The external Url of the web service
The specific Method to call from the above web service
The Xml Namespace used by the Web Service. This is required for a well formed request to the service.

The Handle Namespace option to allow for simpler xpath queries (see below)
The Parameters with their respective values. Each parameter is defined as pair of strings (ParameterName];[ParameterValue) and each pair is seperated by a pipeline (|) from the next one. For example, if two parameters exist, FirstName and LastName and their respective values are John Smith then one should input the following: FirstName;John|LastName;Smith. One can also enter the same values or edit them, using the provided pop-up form.

NOTE: As with everything that has to do with XML, the above values are case sensitive.

When all the above fields are filled properly pressing the Test button shows the result that the web service provides, to confirm their validity. If any error occurs while calling the web service the resulting error will be displayed instead.

The second part of a web service call, consists of defing an XPath Query to be used for extracting the needed information. For each element returned a row will be displayed in the DataGrid with all of its attributes (Auto Populate)

If Handle Namespaces is selected simple xpath queries can be used, e.g.: //z:row[@ows__Level=2].
If Handle Namespaces is not selected the xpath cannot contain prefixed elements and one should reside to the use of local-name(), e.g. //*[local-name() = ‘row’][@ows__Level=’1′].

Any element of the form can be referenced inside the XPath Query, by enclosing its name inside brackets. For example: //sales[@customerId={c_customer_id}.
The {c_customer_id} will be replaced with its specific value before Xpath Querying the Web Service Call result.

You can also select specific Attributes to display using their names, seperated by a semicolon (;), e.g. ows_UniqueId;ows_FileLeafRef.

A different name can be used for displaying purposes, other than the name of the Attribute, if a similar list of headers is filled in the Headers textbox. The Headers should match the respective Attributes one-to-one. If fewer Headers are provided the remainng attributes will use the default (the Attribute’s name). If more Headers are provided they will be ignored.

Example :

Once the user has defined a Web Service call, he can then connect it to a WebServiceDataGrid control. In the Advanced tab one has to select a Value Type of Web Service Call, and then pick a specific web service call from the list box Web Service Post Url. The control will display the matching data using the xpath query and the (optionally) defined attributes in a read-only grid.

The same advanced parametrization can be used in all controls but the resulting value might not be valid. For example a checkbox will parse 0 as not checked and 1 as checked but any other value will be ignored and the checkbox will remain not checked.

NOTE: If the web service is external and in a different domain with .xap file, you will have to place the clientaccesspolicy.xml file in site root folder as shown in the instructions here.

August 15, 2017/by Konstantinos

Knowledge Base, PowerForms Siverlight, Web Services and Web Posts

Manually Calling Web Services

In version 2.0, a new Button control is introduced, which allows users to manualy call web services, or list queries and apply the retrieved data to controls on the form.

Lets see a complete walkthrough to perform this task :

We assume that we already have a web service available.

For our example the web service only has one method (GetCustomer) that returns a Customer object.

The Soap Request and Response follows :

A test execution returns the following sample data :

One Customer record. 3 properties (ID, Name, Balance).

Notice that the “ID” property is serialized as attribute wheras the rest of the properties follow the default pattern (elements).

We now go to our form which looks like this :

We must add the Button control as well as the placeholders for the web service data.

We open the designer and drag-n-drop the controls from the toolbox.

As soon as we place the controls on the form, we switch to the Web Serices section, in order to define the Web Service Call.

We Create a new Web Service call and define the basic parameters (url, method name, xml namespace). Note that all these properties should be available in the Soap Definition.

Next, press the TEST button to read the xml response of the service. It sould be something like the following :

In order to get the required data from the xml, we should use XPATH.

An easy approach to escape from the namespace hell, is to use local names.

Here is my example to retrieve the GetCustomerResult xml node:

/*[local-name()=’Envelope’]/*[local-name()=’Body’]/*[local-name()=’GetCustomerResponse’]/*[local-name()=’GetCustomerResult’]

After setting the XPath property, we define the attributes we want to retrieve (ID, Name, Balance separated with semicolon).

While in the web service designer screen, we can try the web service and examine the retrieved data in the grid.

If everything seems to be fine, we must return to the Button properties and bind it to the Web Service.

We select the Web Service, and we bind the target controls with the attributes retrieved from the service.

We are ready to go now!

Save the configuration and test the button in the final form:

August 15, 2017/by Konstantinos