Fiorano Logo  
     Fiorano Login 
Products
   ESB Best Practices
  Service Design (1)
  Process Development
and Testing (2-7)
  Scalability and Load
Balancing (8-12)
  ESB Process Deployment
(13-14)
  Performance Tuning and
Memory Optimization (15-16)
  Application Integration on an
ESB
   Download PDF Now


Process Development and Testing


Best Practice 2 - Separate servers for different business processes
Best Practice 3 - Error Handling
Best Practice 4 - Explicit Transformations
Best Practice 5 - Version Control Integration
Best Practice 6 - Component Level Testing
Best Practice 7 - Process Level Testing

Best Practice 2 - Separate servers for different business processes

Multiple Services exchanging information across a network constitute an Event-Driven Business Process, more commonly referred to as an "Event Process". In a typical implementation, a Business Process is composed of multiple Event Processes (EP's), where each EP performs a specific activity. The EP's taken together solve the business problem.

The best EP's in practice have the following properties:

Regardless of the particular underlying ESB technology or product, each EP consists of not more than 10-15 components
(i.e.Services) for easier management.

  • On the Fiorano platform, each independent EP uses "port bindings" to communicate with another EP. For instance, if the Business Process definition requires data to flow from EP1 to EP2 then the OUT_PORT of the last component in EP1 is bound to a specific destination (say Status_Update). The IN_PORT of the first component of EP2 is then bound to the above destination (Status_Update), as illustrated in figures 1 and 2 below. The term destination as use in the foregoing refers to a JMS Topic or Queue, as decided by the developer.

Figure 1 : Event Process 1 (MortgageFlow)

Figure 2 : Event Process 2 (MortgageFlowUpdate)

By communicating via the destination status_update, the two event processes ( MortgageFlow and MortgageFlowUpdate ) can communicate with each other.

This approach enables developers to:

•  create and test their flows (EP's) individually.

•  create complex business processes in a modular fashion by splitting them up into EP's instead of using one large monolithic process. The individual EP's can be developed and tested separately and later integrated together by simply modifying the port bindings for the components.

Best Practice 3 - Error Handling

It is best to define a common error process to handle errors across multiple Business Processes. On the Fiorano platform, this is also achieved via the port binding functionality as explained in the previous section.

The Fiorano ESB™ allows each Service Component to be customized via settings. The service component customization sheet includes an Error Panel, that provides various options (including send on, on_exception port, log the message, stop the service etc.) to handle errors/exceptions such as: connection lost, invalid request and others that occur within the component. The default configuration within the Error Panel is to log the errors and publish them on the on_exception port of the component. This Error Panel needs to configured to meet your requirements. For instance, you might wish to stop the service on first error or configure the component retry connections etc.

Best Practice 4 - Explicit Transformations

For easier management of processes and data it is best to use explicit Services rather than implied (or "hidden") transformations. On the Fiorano platform, this is done by using XSLT business components instead of using transformations on routes.

It must be noted, however, that while using separate XSLT components eases the management of your processes by exposing all transformations, each separate component uses up extra memory. As such, if you wish to conserve memory and/or optimize memory utilization, you should implement transformations directly on the routes.

Best Practice 5 - Version Control Integration

As with any other development best practice, it is recommended to keep the al of the files you create/modify in version/source control systems.

The files created in an event-process deployment typically include,

•  Server profiles

•  Event Processes

•  Custom Service Components

•  Custom Mapper Functions

•  Destinations (i.e queues/topics)

All such files should be under source-code version control.

Best Practice 6 - Component Level Testing

It is highly recommended to start building the test cases along with service component development. Regardless of the ESB platform you use, it is almost always possible to write JUNIT test cases for individual services. Such tests must be developed and run regularly.

Best Practice 7 - Process Level Testing

As with individual Services, it is recommended to develop test cases for each process using JUNIT or a unit testing tool. Unit testing of event-processes is described in greater detail in the Fiorano product documentation.

 



© Fiorano Software Inc. All Rights Reserved. Privacy Statement |Terms of Use
  Site Developed & Maintained by Fiorano Webteam.


 World Wide Support
 USA
:
+1-408-354-3210
 INDIA
:
+91 80 4017-0000
 UK
:
+44(0) 19328 95005