Using Jolie to implement BTE transactions

For whom of you that is familiar with SAP and its complex behaviours, the term BTE ( Business Transaction Event  ) should be familiar. For those less familiar with SAP a BTE can be defined as a specific moment ( status ) in  the life cycle of enterprise document. such concept transcends SAP and its implementation of an ERP  For example an Sales Invoice can be represented by a cohesive object that contains all the required information.

In the service oriented programming object as such do no exist instead they are  substituted by operation and they relative input and output messages. In a standard WSDL notation operations and their relative messages are represented in this way 

<message name="createSalesInvoiceRequest">

  <part name="clientCode"    type="xs:string"/>

  <part name="invoiceDate"   type="xs:string"/>

  <part name="invoiceAmount" type="xs:double"/>

</message>

<message name="createSalesInvoiceResponse">

  <part name="invoiceId" type="xs:string"/>

</message>

<portType name="salesInvoiceInterface">

  <operation name="createSalesInvoice">

    <input message="createSalesInvoiceRequest"/>

    <output message="createSalesInvoiceResponse"/>

  </operation>

</portType>

In Jolie the operation can be represented using the following definition

type createSalesInvoiceRequest:void{

   .clientCode:    string

   .invoiceDate:   string

   .orderNumber : string

   .invoiceAmount: double

}

type createSalesInvoiceResponse:void{

      .invoiceId:int

}

interface SalesInvoiceInterface{

 RequestResponse:

    createSalesInvoice (createSalesInvoiceRequest)(createSalesInvoiceResponse)

}

Is not a case that as an example of operation createSalesInvoice was selected as an example: often the communication medium of such document varies from client. Let’s look at some examples

Your customer is :

1.     A big corporation and wants a communication via XML File 

2.     A medium size company that requires PDF

3.     A small company may just want an e-mail

Now let's us define a DocumentInterface

type createDocumentRequest:void{

   .invoiceId:    int

   .invoiceDate:   string

   .orderNumber : string

   .invoiceAmount: double

   .clientInfo:clientInfoType

   .

}

type createDocumentResponse:void{

      .docId:string

}

interface DocumentInterface{

 RequestResponse:

    createDocument (createDocumentRequest)(createDocumentResponse)

}

Now let's us assume that three separate services are created and each of the them is implementing the documentInterface

Now in the service that implements createSalesInvoice we need to define an output port in this way

outputPort DocumentServicePort {

  Location:  "local"

  Protocol:sodep

  Interfaces: DocumentInterface

}

and an implementation of the operation as follow

[ createSalesInvoice(request)(response){

  /*code to save on the DB */

  response.invoiceId = responseDB.invoice

}]{ 

     requestClientInfo.clientCode = request.clientCode;

     getClientInfo@ClientServicePort(requestClientInfo)(responseClientInfo);

     requestDocumentCreator.invoiceId =  response.invoiceId ;

     requestDocumentCreator.invoiceDate = request.invoiceDate;

     requestDocumentCreator.orderNumber = request.orderNumber;

     requestDocumentCreator.invoiceAmount =request.invoiceAmount;

     requestDocumentCreator.clientInfo << responseClientInfo.clientInfo;

     DocumentServicePort.location = responseClientInfo.serviceInfo.location

    createDocument@DocumentServicePort( requestDocumentCreator) (responseDocumentCreator);

}

It can be seen on the line underlined in green how the location of the DocumentService is dynamically this will allow to select the location dynamically depending on the client code the location and therefore its implementation of createDocument.

Let’s go back to our three clients with there relative localtion

1.     A big enterprise =>"socket://localhost:3001"

2.     A medium enterprise =>  "socket://localhost:3002"

3.     A small enteprise=>  "socket://localhost:3003"

Let’s assume now that in the life cycle of the implementation will be necessary to specialize even further the document service

The IT development team will be able to design and develop the new service without having to touch the existing code. Once tested and approved by the business it will be possible to activating by simply adding the new location to all the client master data that need to have this new service

I hope this post has showed some the excellent flexibility capabilities Jolie possess in implement BTE. How a change in a part of the business workflow does not mean long hours of redesign and redeployment. The author does realize that this example centrally does not represent the complexity of a real business work flow, but this post aims to propose Jolie as a serious contend for Business workflow design and implementation