BPEL Learning: Create a simple process

The customer issued a loan request; request to be processed, and the customer figured the loan to be approved. At first, that step in the middle will send an application to the financial institution to enable Web services and will tell the customer. From a customer point of view, the process will use his application and then send him a response.

Establishing Process: The above behavior includes: obtaining a message, then calling the Web Services of the financial institution and final answering customers. These three operations are defined in , , and activity in BPEL. However, this process needs to define the relationship between these simple activities to know how and when to run these activities. These relationships are defined by using structured activities in BPEL, which defines some restrictions on how to run them. In this example, you want these three operations to take one by one. In BPEL, you can use activity to get this order, activity first contains to consume message, followed by a to talk to financial institutions, and finally send to customers in answer. Therefore, the above-mentioned cloud map will contain three activities in this order, and the financial mechanism can be called, as shown in FIG.

Create a service description: Using WSDLBPEL integration on the WSDL description dependence of the services involved, this is to reference messages that are being swapped, the operation being called and the portType belonging to these operations. In this example, you will need a description of the financial institution and this process itself. To consider the use of a unified message to describe the loan information and define these messages in the loan definition of Listing 1.

Listing 1: Loan definition WSDL (LoandingFinitions.wsdl)

XMLns: TNS = "http://tempuri.org/services/loandefinitions"

XMLns: xsd = "http://www.w3.org/2001/xmlschema"

XMLns = "http://schemas.xmlsoap.org/wsdl/">

Assuming that you know a financial institution that provides a loan approval service that describes the following list 2. The financial institution only contains a single operation "AppRove" that uses this operation to determine the status of a loan request. This action uses information about the customer as an input, then outputs a ratification message containing the response. The definition of the input message is defined in the Loandefinitions WSDL above. Listing 2: Loan Approval by WSDL (LoanApprover.wsdl)

XMLns: TNS = "http://tempuri.org/services/loanapprover"

XMLns: xsd = "http://www.w3.org/2001/xmlschema"

XMLns: loandef = "http://tempuri.org/services/loandefinitions"

XMLns = "http://schemas.xmlsoap.org/wsdl/">

Location = "http: // localhost: 8080 / bpws-samples / loanapproval / libandingfinitions.wsdl" />

Message = "Loandef: LoanRequesterrorMessage" />

...

....

The process itself only forwards the input message to this service and forward the output message from this service. Therefore, the flow will provide the same description to the user by reference to the PORTTYPE above. One thing to do is to define serviceLinkType for the service used. ServiceLinkType defines up to two roles. The two roles are referenced by any two services that are linked together by ServiceLinkType and needed Porthpe. For this example, this ServiceLinkType will be used to link the client to the process, and link the process to the loan approval. Because the process itself and the loan batch provide "AppROVER" PortType, only one role is required, and both of them do not require the user to support another porttype. You create the code in the list 3 below: Listing 3: Loan Approval WSDL (Loan-Approval.WSDL)

Targetnamespace = "http://loans.org/wsdl/loan-approval"

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

XMLns: SLNK = "http://schemas.xmlsoap.org/ws/2002/06/service-link/"

XMLns: xsd = "http://www.w3.org/2001/xmlschema"

XMLns: lns = "http://loans.org/wsdl/loan-approval"

XMLns: APNS = "http://tempuri.org/services/loanapprover">

Location = "http:// localhost: 8080 / bpws-samples / loanapproval / loanapprover.wsdl" />

Location = "http: // localhost: 8080 / bpws-samples / loanapproval / libandingfinitions.wsdl" />

All requirements for creating a process created this process are now satisfied. You are defined in the element, including the namespace of the process to reference the required WSDL information (in this namespace (http: //.../loandefinitions), the message definition is defined), the loan approval Target Namespace (http: //.../loanapprover) and procedures their own WSDL target namespace (http: //.../loan-approval). The process can now be used as a component with a loan approval person.

Targetnamespace = "http://acme.com/simpleloanprocess"

XMLns = "http://schemas.xmlsoap.org/ws/2002/07/business-process/"

XMLns: lns = "http://loans.org/wsdl/loan-approval"

XMLns: loandef = "http://tempuri.org/services/loandefinitions"

XMLns: APNS = "http://tempuri.org/services/loanapprover">

The next step is to declare the parties involved. Define named partners, each partner has a WSDL ServiceLinkType indicating its feature. For this example, partners are customer and financial institutions. The partner's Myrole / PartnerRole property specifies how a given serviceLinkType partner and process will interact. The Myrole property is referenced by the role to play in ServiceLinkType, and PartnerRole specifies the role that partners will play. This is elaborated in the partner definition below. The loan approval process provides customers with LoanApproAlpt function, and financial institutions then provide this feature for processes. This relationship can be seen in Figure 1 and 2 above.

ServiceLinkType = "lns: loanappprovelinktype"

Myrole = "approver" />

ServiceLinkType = "lns: loanapprovallinktype"

Partnerrole = "approver" />

After you define your partner, you will basically prepare for activities that start adding a constituent integration. Let's look back at what you want to do. In order to apply for a loan, the customer sends a message to the process, and the process asks if the financial institution will accept the loan application, and then use another message (either accept the application message or a message to apply for a message) to answer the customer. How do you do this in BPEL? First, you need to put incoming messages in BPEL activity to access it. In BPEL, data is written to the data container and access from the data container, which can save an instance of a particular WSDL message type.

From the definition of customer partners and LoanApprovalPT, it can be seen in clear that the customer will send a CreditInformationMAGESSAGE type message and then get an APROVALMESSAGE type of response. Therefore, the following container list has been added, and these containers are represented by blue cylinders in Figure 2:

Interaction with the process: Receive, call, the answering process may only contain one activity, in this example, . Now, you can add a Receive activity to Sequence, which can receive the customer's message and save it to the appropriate container. The definition of the Receive activity must include partners who will send it to the event, and the partner will use the port type and operation of the process of the destination of this message. Based on this information, once the process gets a message, it searches for a Receive activity with a matching Partner-PortType-Operation Triple Group, and then handed the message to this Receive activity. In order to avoid confusion, the BPEL4WS specification specifies that there are not a number of reception activities with the same Partner-PortType-Operation Triple Group at the same time. Subsequently, the activity will put the message in the specified container and then end. You started the Sequence activity, then add received to it:

PortType = "APNS: LoanApprovalPT"

Operation = "approve" container = "request"

CreateInstance = "YES">

The next step is to ask if the financial institution that enables Web services will accept loans. This is done with a conventional web service call, which is defined by the Invoke activity in the process. The Invoke activity will use the message in the Input Container to call the specified Web service and put the resulting response in the output container and then end. Please note: The call will be called on the "Approver" partner to perform the approve operation.

Partner = "approver"

PortType = "APNS: LoanApprovalPT"

Operation = "approve"

InputContainer = "Request"

OutputContainer = "ApprovalInfo">

In order to make the process respond to the customer's request, the process uses a reply activity. Once an answer is arriving, you will find out who is sent to the Partner-PortType-Operation three-way group with the process. Therefore, in order to respond to messages arriving through the Receive activity, you will need a Reply activity with the same ternary group. In this example, you want to tell the customer's decision, so you will find the message to be sent in the output container that is called: ApprovalInfo. After the response, the process ends. You turn off the Sequence tag and process tag.

Operation = "approve" container = "approalinfo">

All combined

After the process is deployed, I have been waiting until someone starts it. If you pay a little attention, you can see that Receive contains a "CREATEINSTANCE" and is set to true attributes. This shows us an entry point for entering the process. Figure 3 illustrates how the loan approval process will run.

Figure 3. Running loan approval process.

Figure: Number indicates the order of the arrow. Black envelopes are messages that contain loan requests. The red envelope is a message containing a response to the request.

After sending a message with an appropriate ternary group to the process manager, a process instance is created and started. In a given example, the process will start sequence, which will then start Receive. The message has arrived, so it will be placed in the "Request" container. INVOKE will then occur. After the message obtained after the call is placed in the "ApproalInfo" container, the reply will get this message and send it to the customer. At this time, the instance of the flow ends. Multiple instances of the same process can run at the same time. When I explain the more complex process, you will see how to use the correlation to route the message to the correct instance of the same process and how to route the message from the correct instance of the same process.