The sections below list certain best practices and relevant features that enable users to get the most out of the Fiorano platform capabilities. The sections outlined are applicable to both developers as well as environment management teams.


 It is assumed that the reader is well aware of the Fiorano Architecture. Please contact Fiorano Support at for any clarifications.



It is important to understand a topology that is best suited for an environment. Fiorano is a completely distributed system where different servers in Fiorano architecture can be deployed in different parts of the network based on the requirements such as the location of DMZ servers and need for disaster recovery. To understand the different topologies, refer to the Deployment Topology page.

Cloud Setup

Refer to Deploying Servers in Cloud to understand the best practices and configuration changes required to deploy the Fiorano server in the cloud and in hybrid environments.


System Management

Linux Level Configuration

Various configurations can be changed in the Linux operating system to optimize the availability of resources to Fiorano. This is discussed in the Managing Linux System-level Configuration page.

Clone Virtual Machine (VM)

It is good practice to clone the VM that is preconfigured with Fiorano installation set up with Java and lock files. Use cloning to make copies of a virtual machine from an already configured machine. These copies reflect the entire file system (with installation files), configuration and settings of the VM from which it is copied. To understand how to prepare a system to clone with Fiorano and changes that needs to be done after a machine is cloned,  refer to the Cloning a Virtual Machine page.



Event Process

microservices per Event Process

Limit the number of microservices in an event process within the range of 15 to 20. This results in quick start up times and manageable workflows. If the requirement seems to grow beyond this number of services, then it is better to use remote service instances to enable inter event process communication.

Develop flows which can be reused across different processes. To achieve this, remote service instances can be used in conjunction with route selectors.

Use Service Launch Order

In certain cases, following an order of execution might be important while different microservices in an event process are getting launched. To launch and/or stop microservices present in an event process in a predefined order, use Service Launch Order.

Load Balancing

Use Load Balancing to distribute messages to multiple business services for processing. To enable service-level load balancing on a service, run multiple instances of the service on different ESB Peers and redirect the incoming data to multiple running instances via a Distribution Service. Refer to the Load Balancing page where an example is given.


It is critical to ensure that the platform scales both with current projects (likely in themselves to be highly distributed, probably across company boundaries) and with future growth. To address scalability issues, refer to the Scaling section.


Changing Business Logic

Customize Business logic of new microservices by modifying the logic while creating them.


Fiorano provides an extensive set of samples which provide best practices to make changes to microservices generated using Fiorano SDK, such as providing multiple ports and generating user defined CPS. Each of the samples is accompanied by a readme.txt which lists out the steps needed to make the changes.



Application Security

Always define user permissions on Applications to control unauthorized access to sensitive information. To perform this, refer to the Access Control List (ACL) based security page.

Improve the security of messages that flow between microservices through an active flow by adding Port or Route Encryption to messages.

Server Security

Establish secure communication between the Enterprise server and the Peer server by configuring the protocol parameters in the server profiles. Refer to the Enabling Server Level Security page.

Web Service Security

It is critical that web services which are exposed in Fiorano are secured properly. Security can be different for different types of web services and can be enforced at different levels.

Jetty Security

All SOAP and REST based web services in Fiorano are hosted in a Jetty Server. A Jetty Server provides the baseline security for the web applications hosted. Refer to the Managing Jetty Security page to understand the best practices with respect to securing Web Services hosted on Jetty.

SOAP Web Services

SOAP web services are hosted using the WSStub microservice. It is good practice to secure these web services using WS Security standards. Refer to the Web Service Security example.

REST Services

In case of REST services, API keys can be used to restrict access to certain users. Configuration and usage of API keys are explained in the Additional configuration section in the RESTStub page.



Monitor using Event Process

Handle Errors using the Exception Listener microservice

Utilize the capability of ExceptionListener microservice which acts as a global exception listener subscribing to exception messages occurring in any service microservice of any running event process. The Performing Error Handling section gives a brief description of its working.

Publish report in Windows Event Viewer

Windows users can enable Writing Fiorano Logs to Windows Event Viewer and view logs in the Event Viewer.

Monitor using Callouts

For more fine-grained monitoring of events happening in a flow, it is possible to define SBW callouts at the port level. The callout option allows custom Business Activity Monitoring from the data being processed by the ESB in an asynchronous manner. Refer to the Configuring SBW Callout page to understand how this works.

Tracking documents for reinjection and Creating SBW Tables manually

The documents that are passing through the entire flow can be tracked using the Dashboard by enabling the Document Tracking option.

Refer to the Document Tracking page to know how to

  • enable Document Tracking in a Workflow of an Event Process
  • create SBW Tables Manually (if the servers lack permissions to create SBW tables)

Refer to the Document Tracking in Dashboard section to track them in the Dashboard.

Memory Management

Optimize Memory

Although Fiorano ESB architecture scales very well in a distributed environment, adopt the strategies mentioned in the Optimizing Memory page to manage memory more effectively.

Tune microservice Memory

To achieve stable, high throughput, and highly optimized memory usage of the Fiorano Environment, it is very important to tune the heap memory allocated to each service microservice and the Fiorano servers. Refer to the Tuning Component Memory page.

Refer to the Component Configuration page to restrict or expand memory used by a microservice based on the requirement by appending appropriate Maximum Heap Size (-Xms) and Initial Heap Size (-Xmx) values as JVM parameters. This section also covers the topics below:

  • Using same JVM settings in Multiple Microservice Instances
  • Using same JVM settings in Multiple Environments
  • Change Default JVM Configurations for Separate Process microservices

Manage Peer Server Memory

To avoid a class of serious problems that could occur because of improper configurations of the Virtual Machine (VM) on which the Server is running, memory tuning and management need to be done to the server. Problems of this sort are very hard to reproduce and can create a lot of confusion with regards to the server behavior. Refer the Managing Peer Server Memory page to manage peer server memory.


Refer to the Recommendations section for recommended JVM parameters in the Managing Peer Server Memory page.

Use In-Memory Launch Mode

Use In Memory execution mode for microservices with less memory footprint such as XSLT and CBR. The JVM server will be used while using microservices in this mode.


Change Management

Use Named Configuration

The configuration set for a particular service instance can be stored by a name to reuse the configuration in other service instances. By using the named configuration support, configurations can be predefined and the name of the predefined configuration can be linked/transferred to all Service Instances. Though the actual configuration has only one location, since it is referred to by multiple Service Instances, making changes to the named configuration will affect all Service Instances automatically. To to advance the process of Event Process Orchestration and Change Management within the Fiorano Event Processes, refer to the Named configurations page.

Event Process Life Cycle Management

Event Processes in Fiorano can be assigned a label which denotes the environment in which they should run with the configuration defined for all required environments. When required, the event process can be changed from one environment to another by a click of a button in eStudio or can be automated using scripts. Refer the Defining Named Configuration and utilize EPLCM page to understand how this works.

Automate Environment Migration

While migrating from one environment to another, it is better to use CLI tools to automate the process. This utility allows the changes that happen to applications (example: environment variables changing) or microservices being deployed on the server.  

The properties that need to be replaced in the application are specified in a properties file. When the Utility runs, it makes the necessary changes as defined in the properties file and deploys the applications on the server.

Change Resources based on Environment property

In certain scenarios, to make changes to resource URLs (like URL in HTTPAdapters) based on the environment, the environment value is provided as a JMS property in the message. It can be used in scripts/if-then-else funclets to adapt to the URL based on the environment. Refer Changing Resources based on Environment property page to check how to do this.


Recovery from Failures

Disaster Recovery Environment

In systems highly sensitive to failure, it is good practice to keep a separate environment for disaster recovery in a different network than the actual deployment. The different disaster recovery topologies are discussed in the deployment topologies page.

Re-inject Failed Documents

It is recommended to have tracking points in flows where a manual replay of messages is not possible or is cumbersome. Fiorano document tracking enables defining important points in an event process so as to  replay failed transactions from these points. The messages to be tracked are saved in a data store in an asynchronous manner without any affect on server performance. Refer to the Re-injecting Failed Documents page to perform this action.


Deleting Document Tracking (SBW documents) data

To save some disk space, schedule a deletion task for the old SBW documents that are tracked; refer to the How to schedule Deletion of SBW Documents page. This helps in avoiding issues such as Low Disk Space error.

Events are temporarily stored in a persistent database, which are created during the runtime data phase of the Enterprise Server. After an event has been processed, it gets deleted from the temporary store. If these events are not processed, the temporary data store may grow to occupy a large amount of disk-space. To delete the data present in various profiles of the Enterprise Server, clear the ESB Server database.

Adaptavist ThemeBuilder EngineAtlassian Confluence