关于如何从workflow将DTO传回C# Client

最新推荐文章于 2024-09-23 13:28:32 发布

viomaple

最新推荐文章于 2024-09-23 13:28:32 发布

阅读量768

点赞数

文章标签： workflow c# webservice service user properties

本文链接：https://blog.csdn.net/viomaple/article/details/546128

版权

曾经我们遇到过这样的一个问题：

由于workflow的一个基本的功能实现就是将webservice有序的串起来我们必须解决在不同的webservice以及C# Client 之间传递数据的难题。这个问题困扰了我们一个多星期之久，我还因为这个难题被老板challenge了一次.....5555

其实直白的点的妙诉问题就是：

Workflow 调用WS1 ，WS1将返回一个ResultDTO ，这个DTO将存储在Workflow的process里面。此时我们再调用WS2 然后返回C#。这是如何将ResultDTO 传回C# 将是一个问题。我们知道C#要主动调用 WS， WS总是被动的，不可能主动的传送数据。

问题的英文Doc 如下：

We are dealing with a demo project about delivery order(DO) handling process. A major step of the process is the DO confirmation, which requires human interaction to manually confirm the DO, consequently, a ConfirmDO webservice is called to update the database, and some result information is generated by the web service and sent back to the caller.

Originally, we handle the situation in this way:

1. The demo process initiates a DO confirmation user task, which requires human interaction to complete it.

2. .NET layer, the caller, call the ConfirmDO webservice to update the database, and get a ResultDTO for information. The ResultDTO carries a flag which indicates whether the database is successfully updated.

3. According to the ResultDTO, .NET layer, call the completeTask webservice to complete the confirmation user task. (Note, the completeTask webservice is created using BPEL API and deployed in a different OC4J with service layer’s)

4. The process then can go to the next activity.

Workflow has no control with the business process, it just waiting for C# ’s message.

See Figure 1 for the original process.

Figure 1

In order to better utilize the process, we changed the process as follows, see Figure 2:

Figure 2

As you can see from Figure 2, the situation is handled in another way(The shaded part is modified):

1. The demo process initiates a DO confirmation user task, which requires human interaction to complete it.

2. .NET layer, call the completeTask webservice to complete the confirmation user task. (Note: the completeTask webservice is created using BPEL API and deployed in a different OC4J with service layer’s).

3. The process invoke the ConfirmDO webservice to update the database.

4. The process then can go to the next activity.

If we do like this, we can be sure when the process got to the next activity, the former one must be executed successfully, and we will be truly using process to control the services.

The second way seems more rational; however, we encountered a problem:

For we need to present the result to user, we need a resultDTO to update the datagrid in C# client. In the clicking button event, we will also write codes for grid updating, together with writing codes for giving user message to bpel process.

The problem is invoking a webservice must be written like this,

So the return value will be send back follow the invoking way to the process .

That means if we want to get a return DTO from the service, we should let another webservice send a message to C# initiatively, we know that is impossible.

So After ConfirmDO webservice is called, how could we return the ResultDTO back to the .NET layer?

经过研究我们相处了这样一个办法：

文档如下：

Solution for BPEL controlled process

1 Definition of Purpose

The purpose of this document is to describe the solution for BPEL controlled process.

2 Description of Problems

2.1 User task

As we all know, user interaction is an essential part of workflow. In BPEL, user task is the mechanism to implement user interaction with a process.

Generally, when a user interaction is required, the BPEL process initiates a user task and assigns it to a certain user. The user can check his/her tasks in the worklist and do necessary operations (update, complete, reject, etc). Right after the task is handled, the result is returned to the BPEL process, which causes the process to call certain web services to do actual work implied in the task. Figure 2.1 illustrates the whole process.

Figure 2.1 BPEL process with user task

2.2 The original usage of user task in BPEL process

Although the standard solution for user task of BPEL process should follow the steps illustrated in Figure 2.1, the current solution is not done in that way. Instead, BPEL process initiates tasks and waits for response as usual, the web service which ought to be called by BPEL process is currently called by the frontier layer (.NET layer in MiniTMS), and task is completed after the web service is successfully called. The current solution can be illustrated by Figure 2.2.

Figure 2.2 current solution

You may find that the web service is by no means orchestrated by BPEL process, instead, the .NET layer works as a controller when handling a user task. We handle this case in this way because some limitations: the web service called may return some data back to the .NET layer for future use. If we use the standard solution showed in Figure 2.1, we simply can not return the data back to the .NET layer because BPEL process does not know where to send the data. Although the current solution works, t is absolutely a deviation from the BPEL principle and may cause problems.

3 Solutions for BPEL controlled process

3.1 Solution description

In order to solve the problem, and use user task properly, we figure out a new solution, which seems more rational.

You may find that the major bottle-neck is the return of data generated by web service to the .NET layer (The demo Loan Flow in BPEL tutorial follows the standard solution but does not return any data back to the frontier layer after CreditRating web service is called).
In the new solution, the main BPEL process(MainFlow) follows the standard steps to deal with user task, and another BPEL process(Callee) is set up for completing the user task and gets the return data generated by web service from communication with the main BPEL process. Since BPEL process Callee is directly called by .NET layer(.NET layer works as the client for Callee), it can return the data by simply call back the client. Figure 3.1 shows how it works.

Figure 3.1 new solution

3.2 Demo for the new solution

A demo project is set up to show implementation of the new solution. Figure 3.2 for MainFlow and Figure 3.3 for Callee. The web service here is CreditRating web service, it simply returns a rating and the rating is treated as the data we need to send back to the .NET layer.

Figure3.2 Mainflow

Figure3.3 Callee

Here is some description for the blocks outlined in the process.

A: initiates a user task and waits response of it.

B: call a web service.
C: return data to the callee.

D: complete the user task.
E: get the return data from the MainFlow.

For more detail, please check the attachment for the demo project.

3.3 How to play around the demo

How to play around? Follow the steps below:

1. Initiate the MainFlow process, the input string is for task customKey. As a result, the MainFlow process is active and a user task whose customKey is the input has been initiated.

2. Initate the Callee process, the input string should be the customKey for the user task you want to complete.

If the input string in step 1 and step 2 are the same, both the processes are completed, Callee can get the return data of CreditRating web service called in MainFlow.

If the input string in step 1 and step 2 are different, MainFlow is stilling waiting for task completion response, and Callee is waiting for the return data from its matching MainFlow process instance.

4 Demo Analysis

In the demo, Two BPEL processes, Callee and Mainflow need to interact with each other. In order to enable these two process instances to interact during run time, correlationset should be used. Correlationset is based on the user-defined properties, and properties are linked to some payload of messages sent between processes.

When two processes instance interact, properties on each part are checked. If the properties match, the two instances are regarded as corresponding ones (See tutorial ABCRouting for another example of correlationset).

Message and correlationset definitions will be covered in 4.1 and 4.2.

4.1 Message Definition

In the demo, we use same message definition for both Callee and Mainflow, for messages for interaction between the two processes should by all means the same. What is more, properties setting are also based on unified messages.

<?xml version="1.0" encoding="UTF-8"?>

<definitions name="Callee1"

targetNamespace="http://xmlns.oracle.com"

xmlns="http://schemas.xmlsoap.org/wsdl/"

xmlns:client="http://xmlns.oracle.com"

xmlns:plnk="http://schemas.xmlsoap.org/ws/2003/05/partner-link/"

xmlns:bpws="http://schemas.xmlsoap.org/ws/2003/03/business-process/">

<!-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

TYPE DEFINITION - List of services participating in this BPEL process

The default output of the BPEL designer uses strings as input and

output to the BPEL Process. But you can define or import any XML

Schema type and us them as part of the message types.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -->

<types>

<schema attributeFormDefault="qualified"

elementFormDefault="qualified"

targetNamespace="http://xmlns.oracle.com"

xmlns="http://www.w3.org/2001/XMLSchema">

<element name="ProcessRequest">

<complexType>

<sequence>

<element name="input" type="string"/>

<element name="credit" type="string"/>

</sequence>

</complexType>

</element>

<element name="ProcessResponse">

<complexType>

<sequence>

<element name="result" type="string"/>

</sequence>

</complexType>

</element>

</schema>

</types>

<!-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

MESSAGE TYPE DEFINITION - Definition of the message types used as

part of the port type defintions

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -->

<message name="RequestMessage">

<part name="payload" element="client:ProcessRequest"/>

</message>

<message name="ResponseMessage">

<part name="payload" element="client:ProcessResponse"/>

</message>

</definitions>

4.2 Correlationset Definition

In the demo, we use the payload of Request Message /ProcessRequest/input as the property for correlationset. When the instances of Callee and Mainflow interact, the payload from both side are checked to see whether they are the same. If they match, the two instances are regarded as corresponding ones.

1. in .bpel file

<correlationSets>

<correlationSet name="CorrelationSet" properties="cor:orderId"/>

</correlationSets>

2. in process .wsdl file

<bpws:propertyAlias propertyName="cor:orderId" messageType="client:RequestMessage" part="payload" query="/client:ProcessRequest/client:input"/>

<bpws:property name="orderId" type="xsd:string"/>

The correlationset setting ought to follow the following steps:

1. Create properties.

2. Assign necessary message payload as the property alias for each property.

3. Create correlationset and add property to it.

4. Set correlationset for BPEL activities when necessary.