To some large extent, NetWeaver BPM is all about composing "edge processes" from SAP Business Suite and 3rd party Web Services. Being able to wire up arbitrary services in a flexible and straightforward fashion is one of the most pivotal contributions of NetWeaver BPM and as such also a crucial value driver. And consequently, this posting elaborates on Galaxy's native integration into the NetWeaver SOA stack. That is, we are discussing what to consider and what to avoid when providing Galaxy processes as Web Services and consuming Web Services from within processes. This time, we are going full circle from modeling service-enabled processes in Process Composer down to configuring the connectivity bindings of deployed processes in NetWeaver Administrator.
The Bright Side: Process Composer
Processes in NetWeaver BPM are exposed as SOAP-style Web Services and can, thus, easily be invoked both from remote clients and other CE (NetWeaver Composition Environment, the platform Galaxy runs on) applications. And actually, providing a Galaxy process as a Web Service is as easy as assigning a service interface (aka WSDL portType) and one of its operations to a start event:
Before you can do so, you have to import the respective WSDL file or create one from scratch. The former may retrieve an existing WSDL definition from various sources such as a URL, the Enterprise Service Repository, or the Service Registry. And actually, that's all you need to do at modeling time. Galaxy will automatically create a Web Service endpoint URL when building the respective archive. At runtime, you may find that URL in NetWeaver Administrator (NWA). Go to Configuration Management / Processes and Tasks/ Process Repository. Select the Development Component where your process resides in from the “Components” table. Selecting the process in question from the “Processes, Tasks, and Rules” table (“Processes, Tasks, and Rules” tab) and clicking onto the “Start Process” button takes you to another page which displays the WSDL operation of the process’s start event and the Web Service endpoint URL where it can be consumed (mind to replace the host and port with your server’s details):
The other way around, when consuming Web Services from an automated activity, there is almost equally little you need to do. When assigning the to-be-consumed Web Service' interface to the automated activity, you have to additionally configure a service group for mass-configured Web Services or, alternatively, a logical destination for individually configured Web Service destinations. Have a look onto the flow below which consumes a simple Web Service enabled EJB "Hallo" from within an automated activity:
The automated activity's property sheet lets you choose and configure its interface (WSDL portType and operation) and binding as described above:
Let's have a look onto logical destinations first. Roughly spoken, a logical destination is a placeholder for a concrete endpoint URL which is then to be configured in NetWeaver Administrator(NWA). Go to SOA Management / Technical Configuration / Destination Template Management. On this page, create a new destination, configure its bindings, security settings, etc.
There, you configure the concrete Web Service endpoint URL to invoke and may also make various security settings. And there you go! There is nothing more you need to do to get up and running with your process and the automated activity therein. While logical destinations are simple to use, they lack a mass configuration facility that would let you make combined settings for a whole range of Web Services provided by a backend system.
For an "enterprise-ready" configuration you will want to go for service groups, instead. Fellow SOA evangelist Alexander Zubev has written acomprehensive summary about SOA Configuration for Connectivity in Composition Environment. For an in-depth understanding of that concept, it might be a good idea for you to read his article. For now, you may simply consider service groups as collections of service references within a business scenario (a group of semantically related processes) which are later bound to Web Services available on a provider system.
From a design time perspective, service groups are closely aligned to the SCA component model where to-be-consumed Web Services appear asreferences. Whenever you configure an automated activity, you have to either create a new service group (or choose from an existing one). When creating a service group from scratch, you can name it at your own convenience and also give it a description:
Under the hood, we will automatically put the interface into that group and also create a service reference which you can find by double-clicking on the “Service References” entry in the project tree:
And that’s essentially all you need to do at design time. Like with logical destinations, there are a few things you need to configure before you can run your process.
The Dark Side: NetWeaver Administrator
First of all, you need to create provider systems for all the systems you consume Web Services from. Go to SOA Management / Technical Configuration / System Connections. Click on Provider Systems and create a new one where you (among others), provide “Services Search Settings”. We won’t go into the details of all those settings. But normally, you will want to go for “Multiple Services”, indicating that a service group can relate to multiple services on a provider system. And that’s what it should do, shouldn’t it? You may then choose from looking up the service endpoint from a services registry (i.e., a UDDI repository) or a WSIL inspection service. Have a look onto the example settings below:
Also mind that you don’t have to create a provider system all the time! Once you have configured your system landscape accordingly, there is no need to create new provider systems (again) all the time.
Next thing you should do is to assign a provider system to the service groups of that are used in your process models. Go to SOA Management / Application and Scenario Communication / Application Communication and browse for the software component and application (i.e., the name of your Process Composer project). The service groups that you have modeled before appears in the lower part of your screen (under the “Service Groups” tab). This is where you can assign the provider system:
Once done, you may also set up a Business Scenario where you can even group multiple Process Composer projects (and the service groups therein) into a jointly configured scenario. To do, go to SOA Management / Application and Scenario Communication / Business Scenario Configuration. There, you may create a new Business Scenario Configuration or assign the service group(s) in your project to an existing one.
Conflict Matrix
Mass-configured service groups that become part of business scenarios are a great way to reduce configuration effort. Then again, there are certain preconditions your processes should meet to make use of (i.e., consume and/or provide) mass-configured services. Whenever you think of large-scale business scenarios involving dozens of processes with an even higher number of consumed services from a multitude of provider systems, service groups are the way to go and it’s worth spending some thoughts on how to model your processes in a way that it complies with those boundary conditions. Vice versa, if you are only in the phase of evaluating Galaxy and are currently trying out some basic features, you may rather stick to logical destinations. In the table below, I have listed some combinations of model configurations in one (“Process 1”) or two process models (“Process 1”, “Process 2”). In Galaxy, any process provides a service (through its start event) and may (optionally) consume services. Services are characterized by a WSDL portType (“service interface”) and a single operation (with its request, response, and fault messages) therein.
Take a look onto the table below where we have listed some typical cases (combinations of portTypes and operations that are used for provisioning/consumption). For instance, an entry “pT1/op1” in the “Provides” column of “Process 1” illustrates that fact that (the start event of) “Process 1” is provided as a Web Service having an interface that uses the WSDL portType “pT1” and its operation “op1”. Fields that are left blank indicate that a certain aspect is irrelevant for the currently highlighted case.
In detail, the different use-cases in the table can be briefly described as follows:
- A process uses different portTypes (and operations, respectively) for providing and consuming Web Services.
- A process uses the same portType but different operations thereof for providing and consuming Web Services.
- A process uses different portTypes but identical operation names for providing and consuming Web Services.
- A process consumes the same Web Service (portType and operation) like another process.
- Two processes are provided as Web Services having different portTypes (and operations, respectively).
- Two processes are provided as Web Services having the same portType but different operations thereof.
- A process is provided as and consumes Web Services having the same portType and operations.
- A process is provided as a Web Service having the same portType and operation that is reused in another process for consuming another Web Service.
- Two processes are provided as Web Services having the same portType and operations, i.e., there the interface is reused in both start events.
Both processes may originate from the same project (Development Component) or from different projects but are assumed to end up on the same server. We also assume that all Web Services (irrespectively of their interfaces and bindings) are provided on the very same server. For instance, a plain Enterprise Java Bean (EJB) may be provided as a Web Service which is then invoked from an Automated Activity.
| Case | Process 1 | Process 2 | Service Group | Logical Destination | |||
|
| Provides | Consumes | Provides | Consumes | Same provider system | Different provider systems | |
| 1 | pT1/op1 | pT2/op2 |
|
|  |
| |
| 2 | pT1/op1 | pT1/op2 |
|
|
|  |
|
| 3 | pT1/op1 | pT2/op1 |
|
|  |
| |
| 4 |
| pT1/op2, |
| pT1/op1, |
|
| |
| 5 | pT1/op1 |
| pT2/op2 |
|  |
| |
| 6 | pT1/op1 |
| pT1/op2 |
|
|  |
|
| 7 | pT1/op1 | pT1/op1 |
|
|  |  |
|
| 8 | pT1/op1 |
|
| pT1/op1 |  |  |
|
| 9 | pT1/op1 |
| pT1/op1 |
|
|  |
|
The Green, Yellow, and Red marker flags indicate whether or not a certain use-case is supported and advisable to be used with service groups or logical destinations, respectively. Use-Cases 1, 3, 4, and 5 are admissible in both configurations. In turn, use-cases 2 and 6 to 9 may cause issues when used with service groups. In detail:
- Using the same WSDL portType to provide a process and consume a Web Service on the same system from this (or another) process (use-cases 2, 6, 7 and 😎 must be avoided when using service groups. This setting may otherwise lead to nasty effects such as non-deterministic invocations of either the application that is provided under this interface (e.g., an EJB that is exposed as a Web Service) or “Process 1” or even recursive process calls (use-case 7). Even if the triggered operations are different (use-cases 2 and 6), consuming a service which has the same portType as a process may fail.
- Providing two processes as Web Services (use-case 9) having the same WSDL portType and operations is only critical if the respective client makes use of service groups and the CE SOA APIs to call those Web Services. When using those APIs in conjunction with logical destinations or even falling back on plain Java SOAP APIs there is no issue with this setting.
Please note that consuming a service S1 having the same portType as another service S2 will only fail if S1 and S2 reside on the same provider system.
Recommendation: Careful when reusing service interfaces on the same system (CE server). To entirely operate on safe grounds, better choose different portTypes and operations for all processes (and other applications that are provided as Web Services). Actually, changing the name space of your portType is all you need to do.
