The sections below list certain best practices and relevant features that enable users to get the most out of the Fiorano platform capabilities in various sections. The sections outlined are applicable to both developers as well as environment management teams.
Deployment
Topologies
It is important to understand a topology that is best suited for an environment. Fiorano is a completely distributed system where the different servers in Fiorano architecture can be deployed in different parts of network based on the requirements like the location of DMZ servers, need for disaster recovery etc. To understand the different topologies, refer the Deployment Topology page.
Cloud Setup
Refer Cloud Setup to understand the best practices and configuration changes required to deploy the Fiorano server in the cloud and 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 Manage Linux System-level Configuration page.
Clone VM
It is a good practice to clone the VM that is preconfigured with Fiorano installation and set up with Java, lock files etc. Use cloning to make copies of a virtual machine from an already configured machine; these copies reflect the entire file system (with the installation files etc), configuration and settings of the VM from which it is copied. To understand how to prepare your system to clone with Fiorano and changes that needs to be done after a machine is cloned, refer the Clone a Virtual Machine page.
Development
Event Process
Components per Event Process
It's a good practice to limit the number of components in an event process in the range of 15 to 20. This results in quick start up times and manageable workflows. If the requirement seems to grow beyond these many number of services, it is better to use remote service instances to enable inter event process communication.
Also, it's always good to 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 components 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 the messages to multiple business services for processing. To enable service-level load balancing on a service, run multiple instances of the service on the different ESB Peers and redirect the incoming data to multiple running instances via a Distribution Service. Refer the Load Balancing page where an example is mentioned.
Scaling
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 the Scaling section.
Components
Changing Business Logic
Customize Business logic of new components by modifying the logic while creating them.
Samples
Fiorano provides an extensive set of samples which provide best practices to affect certain changes to the components 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 to make changes.
Security
Application Security
Always define user permissions on Applications to control unauthorized access to sensitive information. To perform this, refer the Access Control List (ACL) based security page.
Improve the security of messages that flow between components through an active flow by adding Port or Route Encryption to messages.
Server Security
Establish secure communication between Enterprise server and Peer server by configuring the protocol parameters in the server profiles; refer the Enable 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. Jetty Server provides the baseline security for the web applications hosted. Refer the Manage Jetty Security page to understand the best practices with respect securing Web Services hosted on Jetty.
SOAP Web Services
SOAP web services are hosted using the WSStub component. It is a good practice to secure these web services using WS Security standards. Refer Web Service Security example and components documentation.
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.
Monitoring
Monitor using Event Process
Handle Errors using Exception Listener microservice
Utilize the capability of ExceptionListener component which acts as a global exception listener subscribing to exception messages occurring in any service component of any running event process. The Perform Error Handling section gives a brief description of its working.
Publish report in Windows Event Viewer
Windows users can enable to Write Fiorano Logs to Windows Event Viewer for the convenience of viewing logs in 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 to perform custom Business Activity Monitoring out of the data being processed by the ESB in an asynchronous manner. Refer the Configure 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 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 Document Tracking in Dashboard 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 Component 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 component and the Fiorano servers. Refer the Tuning Component Memory page.
Also refer Component Configuration to restrict or expand memory used by a component 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 below topics:
- Using same JVM settings in Multiple Microservice Instances
- Using same JVM settings in Multiple Environments
- Change Default JVM Configurations for Separate Process Components
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 at 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.
Use In-Memory Launch Mode
Use In Memory execution mode for components with less memory footprint such as XSLT and CBR. Server JVM will be used while using components 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 in future. Using 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, as it is referred to by multiple Service Instances, making changes to the named configuration will affect all Service Instances automatically. So, to advance the process of Event Process Orchestration and Change Management within the Fiorano Event Processes, refer the Named configurations page.
Event Process Life Cycle Management
Event Processes in Fiorano can be assigned a label which denotes the environment in which it should run and configuration can be 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 Define Named Configuration and utilize EPLCM page to understand how it 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 were happened to applications (say environment variables have got changed) or components to be deployed to 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 to 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 Change Resources based on Environment property page to check how to do this.
Recovery from Failures
Disaster Recovery Environment
In case of systems which are highly sensitive to failure, it's a 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 and replay any failed transaction from that point. The messages to be tracked are saved in a data store in an asynchronous manner without any affect on server performance. Refer the Re-injecting Failed Documents page to perform this.
Miscellaneous
Deleting Document Tracking (SBW documents) data
To save some disk space, you may schedule a deletion task for the old SBW documents that are tracked; refer How to schedule Deletion of SBW Documents page. This helps in avoiding issues like Low Disk Space error.
Events are temporarily stored in a persistent database that are created during runtime data of the Enterprise Server. After an event has been processed, it gets deleted from the temporary store. If these events are not able to be processed, the temporary data store may grow to occupy a large amount of disk-space. To delete the data present in various profiles of Enterprise Server, clear the ESB Server database.