Test Asynchronous Service from SoapUI (Chapter 12)

Testing asynchronous web services is somewhat special compared to testing synchronous services because in addition to the request message to be sent to the exposed service endpoint, SoapUI also needs to make a callback service available and it has to set the appropriate WS-Addressing headers in the request headers to direct the asynchronous service to the callback service.

SoapUI has a Mock Service facility. This allows us to publish a web service – based on a port type in a WSDL document and published at a port and end point of our choosing. The callback interface is only one way: it receives the response message from the asynchronous service and that is the end of the story. In SoapUI, we can check all messages received by the Mock Service, so we will know if and when the asynchronous service delivered the response. Here is how to do it:

Lees verder

SOA Suite 12c: Dynamically overriding attributes of static routing rules in Mediator component

Routing Rules in a Mediator component carry several attributes that govern the routing rule run time behavior. These include: XSLT or XQuery used for transformation, the filter expression, target operation, the parallel or sequential indicator, the Schematron document used for validation, the native validation and the value assignment (for example for header properties).

image

In SOA Suite 12c, we can conditionally set overriding values for each of these attributes. That means that at run time, based on the evaluation of some expression against the contents of the request message (or the time of the day, day of the week,…) , we can use a different transformation stylesheet or assign a different header value. This dynamic override of the static rule definition is configured using the Override Using option – shown last in the figure overhead.

Lees verder

SOA Suite 12c: Inspect and Leverage the contents of the Run Time MDS in the Integrated WLS

SOA Suite 12c provides the option to use the Integrated WebLogicServer in JDeveloper as the development run time environment. It comes prepackaged, installs very easily and gets a developer up and running in less than 20-30 minutes. As part of this light(er) weight SOA Suite run time, there is an MDS Repository (file based). Deployment to this run time MDS is done in the usual way. The contents of this MDS instance can be inspected in JDeveloper and resources can be transferred to the local design time MDS instance or exported to a JAR file for further distribution. All you have to do is create a connection to this run time MDS instance.

Lees verder

SOA Suite 12c: Using Domain Value Map (DVM) in Service Bus projects

Domain Value Maps are still DVMs in SOA Suite 12c. Create them in JDeveloper, use them in Transformations and Assignments in Mediator and BPEL. Inspect them and edit them at run time using SOA Composer. Nothing really new there.

What is new:

  • In 12c, we can use XQuery in BPEL and Mediator – and in these XQuery functions we can use Domain Value Map as well.
  • In 12c, we can use both XQuery and XSL Map in Service Bus – and here we can use Domain Value Maps as well
  • In 12c, we can inspect and edit Domain Value Maps also at runtime in the Service Bus Design Composer/Console
  • In 12c, we can create Domain Value Maps in Service Bus projects, publish them to the MDS Design Time Repository as well as import them into Service Bus projects from that repository

So as of now, in SOA Suite 12c we can leverage Domain Value Map from Service Bus components.

Lees verder

SOA Suite 12c: BPEL Inline Sub Processes or locally Reusable Chunks of BPEL process logic

imageAn in-line sub process can best be thought of as a callable scope. It is a scope that is not part of the normal process flow, but rather a unit of encapsulated logic that can be called zero, one or multiple times from anywhere within the BPEL process – even recursively from within itself. It is in effect very similar to a private member function in a Java Class or a procedure in the body of a PL/SQL package. Just like private member methods or functions help structuring a Java Class or PL/SQL package, so can subprocesses help organize a large BPEL process – even more than scopes already can.

An in-line sub process can define arguments to be passed in. These can be passed by reference, which means the sub process can alter their values as well. Additionally, the in-line sub process can access all global process variables. The in-line sub process is a scope which as such can define local variables and nested scopes, use partner links, have event handlers etcetera. At run-time, the subprocess code is re-entrant and re-usable – only one copy is stored in memory, even if it is called multiple times. However, on each call, it has a private scope for local and passed-by-value variables.

Lees verder

SOA Suite 12c: Where to find Service Bus Pipeline Alerts (in Enterprise Manager Fusion Middleware Control)

In SOA Suite 12c, the Service Bus specific run time browser interface is not intended for administration activities: all administration around SOA Suite 12c is consolidated into Enterprise Manager Fusion Middleware Control. So a valid question now becomes: how to locate pipeline alerts produced in 12c Service Bus run time environments? These are of course to be found in EM FMW Control. But where and how exactly?

Let’s start with a very simple 12c Service Bus project. This project – was first introduced in an earlier article.

image_thumb[1]

The pipeline receives a fairly simple request message, performs an XQuery transformation on the contents of the $body and returns the result.

Configuring Pipeline Alerts

Create a new Alert Destination – to later on send the alerts to:

image

Set the name for Alert Destination then press Finish:

image

Configure the Alert Destination – ensure that Alert Logging is on (this means that alerts are save to the operational Service Bus infrastructure data store):

image

Open the Pipeline editor. Add an Alert activity to the Request pipeline:

image

Configure the Alert activity as shown here:

image

Most important is the link to the Alert Destination.

The next step is to run the pipeline or the proxy service. In both instances, the service is deployed to the Service Bus run time engine in the Integrated WLS.

Pipeline Alerts at Run-time

In the Enterprise Manager FMW Control, the Pipelines Alerts can be inspected in the home page for the Service Bus node (that takes the place of the Operations tab in the 11g Service Bus Console). The first tab provides an overview of various types of (recent and aggregate) information.

image

The second tab provides details on recent as well as not so recent Alerts. On this tab can selected alerts also be purged.

image

When you click on the alert summary link, a pop up appears with the alert details:

image

On the home page for the Service Bus Project can we check the services in the project.

image

We can  switch to the Operations tab get a more detailed overview per operation of what operational settings have been made. On this page, the pipeline needs to have Pipeline Alerts enabled in order for pipeline alerts to be produced from it:

image

By clicking on an operation (service, pipeline, split join), we can drill down to the next detail page where largely the same information is presented and can be manipulated.

image

If we enable monitoring, the Service Bus will start to collect aggregate information about the number of messages, errors, alerts etc. This information can be reviewed on the Dashboard tab for the Pipeline:

image

Clearly we have made some additional test calls to the service – already six alerts have been counted!

SOA Suite 12c: Exploring Dependencies – Visualizing dependencies between SOA artifacts

SOA composites as well as Service Bus projects typically consist of fair number of artifacts that hang together in ways that are sometimes not so easy to track down. Through import statements, hard coded references and other direct or indirect definitions, dependencies are registered between the many files that make up the application. From BPEL component to WSDL to XSD to other XSD is a not too uncommon path. However, for developers it can be quite a challenge to get a good grasp on these dependency paths. Inspired by – and perhaps more than just inspired – the App XRay feature in OEPE (Eclipse), JDeveloper 12c ships with the Dependency Explorer. This is a tool that can be set upon almost any artifact in SOA composites or Service Bus projects. It will leverage all its built in knowledge about potential dependencies and it will visualize these dependencies.

For example, let’s look at this simple Service Bus project. Right click on the pipeline definition in the navigator window and select the option Explore Dependencies:

image

The dependencies for this simple case are shown like this:

image

In the Dependency Explorer itself, we can right click all components listed and drill further down, list the reference details, select the component in the navigator or bring up the editor for the component.

Here is the drilled down overview of dependencies, starting from the WSDL document ProxyService.wsdl and backtracking what are the references to the WSDL document.

image

In a previous article, we introduced the SOA Suite 12c support for XQuery library modules.

We can open the dependency explorer for an XQuery library

image

and learn where it is used:

image

This overview tells us that we will indirectly impact the ProxyService if we do something wrong with the TimeAndDateLibrary.xqy.

An even more impressive overview is produced by exploring the dependencies for a BPEL component, as is shown here:

image

This results – in this particular example – in:

image

One final example shows how a Database Adapter was analyzed – both the usage from the SB Business Service and the reference to the WSDL and indirectly the XSD:

image

How to create an if-then-else expression (aka ternary operator) in an XPath 1.0 expression?

There are situations where I have to create an XPath expression that performs something like if-then-else logic (similar to a CASE or DECODE expression in SQL or a ternary operator in Java or JavaScript). Unfortunately, XPath 1.0 – a version still widely found – does not support the XPath 2.0 if-then-else logic. So something else is needed.

I encountered a great trick in a forum post; this post also referred to Becker’s Method. In short, the trick uses the fact that the numerical evaluation of (Boolean) true = 1 and of false = 0. It also makes use of the fact that substring( somestring, 1, 0) returns an empty string.

The abstract XPath expression used for

if C1 then R1 else R2

becomes

concat( substring( R1, 1,number (C1) * string-length(R1), substring( R2, 1, number(not(C1)) * string-length(R2)

when R1 and R2 are not of type string, then some type conversion to and from string are required.

An example of using this trick:

In a Mediator component I want to assign the value ‘LONG’ when the input string is longer than 6 characters. When the stringlength is 6 or less, then I want to assign the value not long.

With the ternary expression, this would be something like:

result = (input.length() > 6? ‘LONG’: ‘NOTLONG’)

The corresponding XPath expression is this:

concat(

  substring( ‘LONG’, 1, ( number(string-length($in.payload/client:process/client:input)  > 6)  * 4))

, substring( ‘NOTLONG’, 1, ( number(string-length($in.payload/client:process/client:input)   <=  6)  * 7))

)

image