Code review

Allow to use the generated Java proxy in the browser session, shared between all JSPs:

If the Update button of the HTML form was used, then the content of the text field myEndpoint is passed in the HTTP request; this is then set in the proxy and stored in the local variable endPoint and rendered later in this JSP. Otherwise, the default service endpoint of the proxy is stored in the local variable; this default is derived from the WebSphere Process Server wsdl that was used to generate the proxy:

The remainder of the setEndpoint.jsp file contains the code to render the service endpoint URL, a hyperlink to test the service endpoint URL, and a HTML form to submit a new value for the service endpoint URL. This submit is done by using a push button with label Update that calls this JSP again.

Allow to use the generated Java proxy in the browser session, shared between all JSPs:

Create an empty parameter object for the queryProcessTemplates operation, then use the Java proxy to launch the query operation:

The response data are in the bfmResponse object now. Use the getter method to extract the list of process templates into an appropriate array:

The remainder of the invoke.jsp file contains the code to iterate over the array and render the template data as HTML table.

Allow to use shorthands instead of the fully qualified class names (for example, SOAPElement instead of javax.xml.soap.SOAPElement) in the remainder of the JSP file:

Allow to use the generated Java proxy in the browser session, shared between all JSPs:

Get access to the mechanism for creating SOAP elements:

Create a new SOAP message with no elements inside yet. This will become our input message later on:

Now create the business object that will be part of the input message. The details have to be in sync with the business object definition of the business process template. First, the business object itself is created. In the next step, the attributes ("firstName", "lastName",...) are created, and subsequently the values (myFName, myLName,...), which were extracted from the HTTP request, are attached to them using the addTextNode() method. Finally, the attributes are linked to the business object using the addChildElement() method. Note that the indentation used here does reflect the nesting of the elements rather than the nesting of the Java programming logic:

The third attribute of the "customer" business object is a business object itself, it has the name "address". This child business object is created the same way as the parent business object and then linked to the parent:

Now attach the business object to the SOAP message created earlier:

Create the set of parameters needed for calling the sendMessage operation, which is used for starting a long-running BPEL process. The parameters are process template, porttype, operation, and the input message:

Create an object for storing the result of the sendMessage operation, then call the sendMessage operation with the help of the Java proxy:

Extract the Process Instance ID (PIID) from the response that was returned by the sendMessage operation. This PIID can be used as handle to the process instance details later:

The remainder of the startprocess.jsp file contains the code to render the parameterized URL for calling the viewprocess.jsp page and some basic exception handling.

Allow to use shorthands instead of the fully qualified class names (for example, SOAPElement instead of javax.xml.soap.SOAPElement) in the remainder of the JSP file. Here, we do not create new SOAP elements, so we do not need the shorthand for the SOAPFactory.

Allow to use the generated Java proxy in the browser session, shared between all JSPs:

Note: In this JSP file, we want to add the refresh directive to the HTTP header conditionally, thus the relevant Java code has to be merged into the HTTP header rather into the HTTP body.

Create the objects for the request and for the response of the getProcessInstance operation:

Provide the PIID which was extracted from the HTTP request, then launch the getProcessInstance operation:

Note: When starting a long running process with the BPC Explorer, the user is allowed to specify an arbitrary process instance name (the only constraint is that it has to be unique). For the getProcessInstance operation, that unique name is accepted as valid PIID value. However, in other operations that take a PIID as input (for example, getInputMessageForProcessInstance) the internal PIID is required.

That is why the PIID is queried again from the system and stored in the variable myInternalPIID and used in other operations that rely on a PIID:

After running the operation getInputMessageForProcessInstance, extract the content from the response:

Look for an element with XML tag "firstName"; to allow checking for null pointers, store the result of the item(0) method in a variable. If all checks for null pointers are passed successfully, concatenate the actual value to the Java variable which will be used for rendering later:

Extract the ExecutionState from the process instance object into a Java String. In case the process is still running, set a boolean variable which conditionally includes an auto-refresh directive to the HTML header:

When the value "STATE_FINISHED" is found as ExecutionState, the output message is extracted in the same way as the input message has been extracted earlier. In addition to the value, the name of the output variable is retrieved by the getNodeName() method. This way, the viewprocess.jsp can be used for monitoring arbitrary long-running process instances and display the first element of the output message.
Keep in mind though that for running process instances frequent polling will happen, which may add some extra load to your system.

The remainder of the viewprocess.jsp file contains the code to render the process instance data as an HTML table.