...
The sections below list certain best practices and key terminologies that may be needed for optimal use of the Fiorano platform . The first in the list is the Fiorano Architecture to help the administrator familiarize the Fiorano platform, as a better understanding of the platform architecture will help the administrator plan better and achieve an optimal deployment of the same. Rest in the sections consist of various runtime aspects of the platform and optimizing the message flows and resource utilization. Finally, the most important practice that needs to be kept in mind, that is, disaster recovery. Since disasters are not planned, the disaster recovery section lists certain features of the product that may be kept active at all times to help recover from nearly all types of failures.
| Note |
|---|
Best Practices may not be fixed for everyone, it depends from environment to environment and also as per the need of the client |
| Tip |
|---|
At any point of time, if you feel that you are not able to understand any part of this document clearly, please contact Fiorano Support at support@fiorano.com |
| Panel |
|---|
Deployment |
Deployment Architecture
Fiorano Architecture comprises of Fiorano Enterprise Server, Peer Service Containers installed across the network together with the centralized Management and Repository Server as well as Management tools. A typical Fioranom Deployment Architecture looks as in the figure below. Click the figure to know more.
The FES is the central controller of the Fiorano Network, acting as a monitoring agent for all the other Peers while ensuring information coherence. The FES is primarily a JMS Server (FioranoMQ Messaging Server) wrapped with additional role specific functionalities. The FES communicates with the FPS using the underlying JMS server and expose well defined JMX and Java API to communicate with the tools. Click the below image to read more.
Cloud
While using cloud environment to run Fiorano, you may require to make some changes to setup different modules in Fiorano. Refer the Cloud Setup section to go through the various changes required.
Document Tracking
It is recommended to use an external database for Document Tracking; refer the Document Tracking section to utilize the database availability optionsin various sections. The sections outlined are applicable to both developers as well as environment management teams.
| Tip |
|---|
It is assumed that the reader is well aware of Fiorano Architecture. Please contact Fiorano Support at support@fiorano.com for any clarifications |
| Panel |
|---|
Development |
Event Process
Components per Event Process
It is 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 this many number of services it is better to use remote service instances to enable inter event process communication.
It is also a good practice 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 it might be important for an order to be present 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
Used 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 routes incoming data to the multiple running instances via a Distribution Service. Refer the Load Balancing section 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. Refer the Modifying Business Logic section.
Samples
Fiorano provides an extensive set of samples which provide best practices to affect certain changes to the components generated using Fiorano SDK, like providing multiple ports, generating user defined CPS. Each of the samples are accompanied by a readme.txt which lists out the steps to make changes.
| Panel |
|---|
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 section.
Improve the security of messages that flow between components through an active flow by adding Port or Route Encryption to the messages. Refer the Message Encryption section.
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 section.
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 Manage Jetty Security section 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 Additional configuration section in RESTStub.
| Panel |
|---|
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 convenience. Refer the Write Fiorano Logs to Windows Event Viewer section.
Monitor using Callouts
For more fine-grained monitoring of events happening in a flow, it is possible to define 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 section to understand how this works.
Tracking documents for reinjection
The documents that are passing through the entire 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.
| Panel |
|---|
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 location of DMZ servers, need for disaster recovery etc. To understand the different topologies, refer this page.
Cloud Setup
Refer this section to understand the best practices and configuration changes required to deploy the Fiorano server in cloud and hybrid environments.
| Panel |
|---|
Memory Management |
Optimize Memory
...
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. Refer the Using 'In Memory' Launch Mode section to understand how to use this mode.
Deleting Document Tracking (SBW documents) data
To create 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 section. This helps in avoiding issues like Low Disk Space error.
events are temporarily stored in 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 datastore may grow to occupy a large amount of disk-space. To delete the data present in various profiles of Enterprise Server, clear Clearing ESB Server Database
| Panel |
|---|
Environment Change Management |
Use Named Configuration
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 section.
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 click of a button in eStudio or can be automated using scripts. Refer this page to understand how it works.
Automate Environment Migration
...
When migrating from one environment to other, it is better to use CLI tools to automate the process. Refer Work with Command Line Interface (CLI)
...
To make changes to resource URLs (like URL in HTTPAdapters) based on environment in such scenarios, 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 section to check how to do this.
| Panel |
|---|
Development |
Event Process
Use Service Launch Order
To launch and/or stop microservices, present in an event process, in a predefined order use Service Launch Order.
Load Balancing
Used 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 routes incoming data to the multiple running instances via a Distribution Service. Refer the Load Balancing section 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. Refer the Modifying Business Logic section.
Samples
Fiorano provides an extensive set of samples which provide best practices to affect certain changes to the components generated using Fiorano SDK, like providing multiple ports, generating user defined CPS. Each of the samples are accompanied by a readme.txt which lists out the steps to make changes.
| Panel |
|---|
Security |
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 Manage Jetty Security section 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 Additional configuration section in RESTStub.
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 section.
Improve the security of messages that flow between components through an active flow by adding Port or Route Encryption to the messages. Refer the Message Encryption section.
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 section.
| Panel |
|---|
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 convenience. Refer the Write Fiorano Logs to Windows Event Viewer section.
Monitor using Callouts
For more fine-grained monitoring of events happening in a flow, it is possible to define callouts at the port level. Refer the Configure SBW Callout section.
Document Tracking
The entire activities of microservices 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.
| Panel |
|---|
System Management |
Linux Level Configuration
Refer the Manage Linux System-level Configuration section.
Clone VM
For Virtual Machine (VM) users, use 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. Refer 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 section.
| Panel |
|---|
Recovery From Failures |
Disaster Recovery Environment
It is a good practice to have a separate environment for disaster recovery in a different network than actual deployment can be employed in case of systems which are highly sensitive to failure. The different disaster recovery topologies are discussed in the deployment topologies page.
Re-inject Failed Documents
In case a component fails to process a message, doc tracking helps to re-inject this message into the system to make sure we do not lose content that needed processing; refer It is recommended to have tracking points in flows where 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 asynchronous manner without any affect on server performance. Refer the Re-injecting Failed Documents section to perform this.
High Availability
The importance of 24X7 service availability and the growing importance of conducting real-time business are driving the demand for High Availability Enterprise Systems. The goal is to maximize system availability and eliminate any single point of failure. The High Availability section discusses the High Availability (HA) features provided by the Fiorano Platform.
| Panel |
|---|
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 section. This helps in avoiding issues like Low Disk Space error.
events are temporarily stored in 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 Clearing ESB Server Database