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.
Deployment
Topologies
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.
Development
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.
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 to the Scaling section.
microservices
Changing Business Logic
Customize Business logic of new microservices by modifying the logic while creating them.
Samples
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.
Security
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.
Monitoring
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.
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.
Miscellaneous
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.