Web Service
So far, we have discussed two methods to reference existing business logic in XPages. Web services is a third option and it will leverage the same technique described in the Java section: the ability of Server Side JavaScript to call Java. Instead of calling your business logic, we will use JavaScript to access JAR files distributed with the IBM Lotus Domino 8.5 server. These JAR files provide the Web Services client framework providing access to web services. In this article we will use Apache Axis and the extensible type mapping framework (javax.xml.rpc.encoding). Web services can not be used by XPages to access business logic running on the same Lotus Domino server because a deadlock condition might occur in the HTTP server. This restriction prevents XPages from using Web services to call an applications business logic, but we include this technique here because Web services can be used to access business logic running in another application on a different server.
In the LotusScript section a "Credit Rating" scenario is discussed. A new label was added, with a computed value using Server Side JavaScript to call an agent. The return value from this formula is displayed as the label contents. Web services would be a viable alternative, if the "Credit Rating" business logic was in another application on another server. A new label would be added, with a computed value using Server Side JavaScript to call the Web service. Lets walk through that code
JavaScript code to call a Web service to operate on parameters, and return a value.
|
|
var service = new org.apache.axis.client.Service;
|
|
|
var call = service.createCall();
|
|
|
|
|
|
call.setOperationName( "CalcCreditRating" );
|
|
|
var xmlType = new javax.xml.rpc.encoding.XMLType();
|
|
|
call.addParameter("INPUT1", xmlType.XSD_STRING, javax.xml.rpc.ParameterMode.IN);
|
|
|
call.addParameter("INPUT2", xmlType.XSD_STRING, javax.xml.rpc.ParameterMode.IN);
|
|
|
call.setReturnType(xmlType.XSD_STRING);
|
|
|
var a = new java.lang.Object[2];
|
|
|
|
|
|
|
|
|
var rating = call.invoke(a);
|
|
|
print ("return value from web service = "+rating);
|
|
|
|
We will only describe the Web service client code. A Web service provider must also be implemented for the sample above to access. In this case, the author used another Lotus Domino 8.5 server as the Web Service provider. This Web service accepted two strings as input arguments and returned a string for the credit rating. Any Web Services provider is acceptable, but some of the sample code might require minor modifications.
On line (1) and (2) we create the Service and Call object to access the Web service. We then associate the Call object to the WSDL (3) which defines the available operations. We must specify the operation we plan to call (4) because a Web Service can contain multiple operations. The next lines (5 - 8) define the arguments, the input argument (6) and (7), and the return (8). The string arguments are passed as an array (9 -11), and then the call is invoked (12). The "Credit Rating" is returned (14) to the computed value and displayed as the label.
The example above was written in JavaScript and calls the Apache Axis and the extensible type mapping framework (javax.xml.rpc.encoding) JAR files. Any Web Services client framework can be used. Apache Axis was selected because it is distributed with the Lotus Domino 8.5 server. If you prefer to develop your solutions in Java instead of JavaScript then develop your code in Java, package the JAR file as described above in the Java section and call your routines from JavaScript. With Java, you can test your logic using JUnit and debug any problems before calling it from XPages.
Unfortunately, the above described code will not work in Domino 8.5.2 (and probably above), due to changes on how org.apache.axis.client gets distributed with Domino. You will probably get an
'org' not found exception.
The workaround to fix this, is to download the Apache Axis framework from their
homepage
and include the jar files into the application as described in
Using existing Java in an Xpage.
This will cause a security error involving the "class loader".
To get around that, the line
permission java.lang.RuntimePermission "getClassLoader";
needs to be added to the server's
java.policy file.
For other techniques for reusing business logic from XPages please see
this article here.