WSO2 Business Process Server v3.1.0 Documentation

##### Overview

- Home
- Release Note
- WS-BPEL Compliance
- License

##### Downloads

- Releases

##### Installation Guide

- Installing WSO2 BPS

##### Quick Start Guide

- Modeling the process
- Deploying the process
- Testing the process

##### User Guide

- Deploying BPEL Processes
- Deploying Human Tasks
- Managing BPEL processes
- Managing BPEL process instances
- QoS for BPEL processes
- Securing BPEL processes
- Invoking secured partner services
- Versioning
- Management API

##### Human Task Guide

- Human Tasks Quick Start Guide
- Deploying HumanTasks
- Managing Tasks
- Developing a Human Task Artifact
- Human Task Management and Configuration
- Human Task Concepts

##### Administrator Guide

- External data sources Configuration
- Registry Configuration
- Events
- Unified Endpoints
- BPEL Extensions
- Transaction Factory Configuration
- Message Exchange Interceptors
- OpenJPA specific properties
- JMS Transport Configuration
- Process Instance Cleanup Tasks
- Process Hydration and Dehydration
- Enabling Peer-to-Peer(P2P) Communication
- Setting up a BPS Cluster

##### Best Practices

- Process Deployment Best Practices

##### Concepts

- Process Versioning
- Process instance events
- Partner links

##### WS-BPEL Extensions

- Activity Failure and Recovery
- Extension Activities and Extensible Assign Operations
- XPath Extensions
- Iterable ForEach
- Flexible Assigns
- BPEL4People Extension

##### Samples

- HelloWorld
- If-Else
- ForEach
- While
- Repeat Until
- Flow and Links
- Pick
- Synchronous and Asynchronous Service Invocations
- Fault Handling
- Split
- XslTransform
- Compensation Handler
- Event Handler

##### Resources

- FAQ
- External Articles
- Library
- Source Code

##### Community

- Forum
- Mailing Lists

##### Project Information

- Issue Tracking

# Deployed Services

Services Service Groups Policies Parameters WSDL files Try It The Service List page allows you to manage different kinds of services and service groups. If your service is successful, it will appear on this page. If not, it will be indicated by the Faulty Service Groups link (which appears in red.)

Figure 1: Deployed Services

## Services

The WSO2 Carbon provides many tools to manage the services that have been deployed successfully with WSO2Server. When you deploy a single service in a service archive, the archive file name will always be used as the service file name, unless you have a name attributed to the service file. If the name of the service archive file is Test.aar, then the name of the service will be Test.

The Service Details page provides detailed information about a particular service.

Figure 2: Service Dashboard

### Service Details

The Service Details panel provides the details of the service.

1. Service Name
2. Service Description
3. Service Group Name
4. Deployment Scope
5. Service Type

Figure 3: Service Details

### Service Statistics

The Statistics panel provides statistics of the service.

1. Request Count
2. Response Count
3. Fault Count
4. Max,Min,Average Response Times

Figure 4: Service Statistics

### Response Time

The WSO2 Carbon provides a graphical view of the system response time.

Figure 5: Response Time vs Time

### Endpoints

The WSO2 server is set to two endpoints by default.

1. https://10.100.1.147:9443/services/HelloService/
2. http://10.100.1.147:9763/services/HelloService/

### Quality of Service Configuration

The WSO2 Carbon provides a number of tools to manage the service quality. You can activate the tools individually as required.The tools incorporated into Carbon are:

1. Security
2. Reliable Messaging
3. Response Caching
4. Access Throttling
5. Policies
6. Transports
7. Modules
8. Operations
9. Parameters
10. MTOM SOAP Message Transmission Optimization Mechanism (MTOM) is a widely used mechanism for sending attachments with SOAP. By default, MTOM is set to optional. You can set it to True or False.

Figure 6: Quality of Service Configuration

Note: Help files for each tool are available from their respective pages.

### Client Operation

WSO2 Carbon provides two client operations. They are, Try this service and Generate the Client.

#### Try this service

Figure 7: Client Operations

You can check whether your service provides the desired output using the TryIt option. When you click Try this service, you will be directed to the page where the operations available for your service will be displayed. When you give the parameters for the operation, a button corresponding to your service appears. You can find further details here.

Figure 8: Check the Service

#### Generate the client for your service

You can easily generate the client for your service using the WSO2 Carbon. The WSDL2 code options are available on the WSDL2 page.

You will see the links to the WSDL 1.1 and the WSDL 2.0 files in the browser.

## Policies

WS-Policy Attachment specification defines a set of policy subjects that can be used when we want to attach or apply security policies. For example, we can attach security policies either at service-level, operation-level or even at message-level.

WSO2 Carbon has the power of Axis2 to apply WS-Policy for your services at different levels such as service, service operation, service operation message, binding, binding operation, binding operation message, etc..

### Defining Policies at Bindings

The WSO2 Carbon has the ability to apply policies at the binding hierarchy. You can apply policies at three different policy subjects in the binding hierarchy. They are;

1. Binding level
2. Binding operation level
3. Binding message level

If you want to add a policy to SOAP 1.1 and SOAP 1.2 bindings at Binding level, you can define it in the services.xml by adding the following code.

<wsp:PolicyAttachment xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">

<wsp:AppliesTo>

<policy-subject identifier="binding:soap11" />

<policy-subject identifier="binding:soap12" />

</wsp:AppliesTo>

<wsp:Policy wsu:Id="binding_level_policy" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">

</wsp:Policy>

</wsp:PolicyAttachment>

For the Binding Operation level, the <wsp:AppliesTo> element is used to define the scope of the policy.

The XML snippet is as follws.

<wsp:PolicyAttachment xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">

<wsp:AppliesTo>

<policy-subject identifier="binding:soap11/operation:Echo" />

<policy-subject identifier="binding:soap12/operation:Echo" />

</wsp:AppliesTo>

<wsp:Policy wsu:Id="binding_level_policy"

xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">

</wsp:Policy>

</wsp:PolicyAttachment>

For the Binding Message level for the out message, the configuration is similar. The identifier attribute of the <policy-subject/> element in <wsp:AppliesTo> changes to "binding:soap11/operation:echo/out".

The XML snippet is as follws.

<wsp:PolicyAttachment xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"><wsp:AppliesTo>

<policy-subject identifier="binding:soap11/operation:secureEcho/in" />

<policy-subject identifier="binding:soap12/operation:secureEcho/in" />

</wsp:AppliesTo>

<wsp:Policy wsu:Id="binding_level_policy"

xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">

</wsp:Policy>

</wsp:PolicyAttachment>

Note: Further details can be found at,

- https://wso2.org/library/3786
- https://wso2.org/library/23
- https://wso2.org/library/3132
- http://msdn.microsoft.com/en-us/library/ms996497.aspx

## Service Groups

A service group is a convenient way of deploying multiple services in one service archive file. There is a logical relationship between the services at runtime. The only difference in the services.xml for a service group and a single service is its root element. For a service group, the root element is serviceGroup, and we have multiple service elements inside the serviceGroup element.

For example:

<serviceGroup>

<service name=Test1>

-----------------------------

<service>

<service name=Test2>

-------------------------------

</service>

</serviceGroup>

The WSO2 Carbon provides the following functions to manage the service groups.

1. Managing the parameters of the service group
2. Managing the module engagements
3. Creating the archive file

Figure 9: Service group dashboard

### Manage Service Group Parameters

We can define parameters inside the services.xml as an immediate child element of the service element. These parameters can be accessed using the message context (at the runtime) or AxisService or AxisOperation. A parameter has one mandatory attribute and one optional attribute. The mandatory attribute is the name of the parameter while the optional attribute is the locked attribute. The idea of a locked attribute is to express whether we allow the parameter value to be overridden by a child node in the hierarchy.

For example, if we add a parameter in the axis2.xml file setting the locked attribute to True, then if a service tries to add another parameter with the same name, it will give an exception .

The WSO2 Carbon provides an easy method to generate the Service Group parameters.

Figure 10: Adding service group parameters

### Manage Module Engagements

There may be some instances where we cannot run our service without engaging the WS-Security module into the service. Engaging a module is just a matter of adding a module tag into the services.xml. If the module is available then the engaging will take place, else it will be a faulty service.

The WSO2 Carbon provides the following modules which you can engage into your service.

1. WSO2xfer-2.2
2. Rampart-1.00
3. Rahas-1.00
4. Savan-1.00
5. Sandesha2-1.00
6. WSO2mex-2.2
7. Addressing-1.41

Figure 11: Engaging a module

You can see further details here.

### Create Service Archive

When you click Create Service Archive on the Service Group Dashboard page for your service, it will create the service archive file. You will be prompted to save the file somewhere else in your machine.

You can find further details here.

## Parameters

The Service Parameters page is used to add service parameters to your service.xml. Click Add New and enter the parameter name. In the TODO section of the parameter that was added, enter the value for your parameter.Click Update to add your newly created parameter into your service.xml file.

Figure 12: Service Parameters

## WSDL Files

You will be able to get the WSDL 1.1 and WSDL 2.0 files from the Deployed Services panel. When you click the particular WSDL link, the WSDL file of your service in the browser.