Components
Clustering provides Adeptia Suite components helps in running Adeptia Suite by grouping multiple servers, hence providing high-availability , and scalability , and manageability of the resources by grouping multiple servers running Adeptia Suite. This is done with the help of components that . The components of Adeptia Suite are discussed below:
Kernel
...
When you enable clustering in Adeptia Suite, it is enabled only for Kernel, not for WebRunner. If you want to load balance the GUI requests, you can use an external load balancer for WebRunners (see Figure 1). Make sure that WebRunner runs on all the nodes. Secure Bridge and Secure Engine users must always use an external load balancer.
...
- Adeptia Suite does not provide Clustering or Fail-over setup for the databases, however, you can set according to the database you use. For load sharing purposes, it is recommended to configure master/slave or replication (refer to the related database documentation).
Log Database:
Adeptia Suite maintain logs of the design time and run time activities that you run within Adeptia Suite. For example, Process flow log, event log, and more. Adeptia Suite writes all these logs into to the log database.
Log database in Clustering mode
...
- All the nodes of the cluster must use same log database.
- In addition, for load sharing purposes, it is recommended to configure master/slave or replication (refer to the related database documentation).
...
...
Shared Location
Adeptia Suite stores intermediate data to enable fail over capabilities and scalability. This data is be used throughout the process flow execution. It is important that the intermediate This data can be accessed by all the nodes of a cluster. So, before enabling a cluster, you must set up a shared location that has both read and write permissions, and that can can be accessed by all the nodes of a cluster. Depending on your operating system and needs, you may use any of the File Sharing services. Some of the popular options include NFS, Samba / CIFS, and SSHFS.
...
When the process flow is executed, data from the source is converted to an intermediate form and then dispatched to the target. The intermediate data is stored in a the repository folder. This should must be a shared folder in the network , which and can be accessed by all the nodes of the cluster. There should not be any username/password required to connect this folder.
...
During execution of a process flow, its current state is stored in a recovery file. These This recovery files are file is stored in a recovery folder. Whenever a process flow aborts due to Kernel shutdown, the Recovery feature handles it automatically with the help of the recovery files. These files, remains in the recovery folder unless the process flow execution is completed. This folder should be shared among all the nodes of the cluster.
...
The process flows may be aborted due to various reasons (for example, incorrect data mapping or schema definition). While execution, at every checkpoint, the Process Flow stores its current state in a rerun file. With the help of these files you can rerun the process flow. These files are stored in a rerun folder , this folder should also and should be shared among all the nodes of the cluster.
Others
When applicable, the following additional folders must also be shared amongst all the nodes of the cluster.
| Folder Containing | Property |
|---|---|
| Web Services Data | abpm.webservice.wsdlDeployPath |
| Attachments | abpm.webservice.metro.soapattachment.location |
| File Reference | abpm.filereferences.basefolder.location |
| EDI Data | abpm.solution.edi.dataFile.location |
| Non-EDI | abpm.solution.nonedi.dataFile.location |
| EDI Archive | abpm.solution.edi.repository.archive.path |
| Security(KeyStore and KeyManager) | abpm.security.repository |
| Jasper Report | abpm.reporting.repository |
| FTP Logs | abpm.ftpDebugOut.file.location |
| SAP | abpm.sap.idoc.repository |
| Process Flow Archive Repository | abpm.transaction.repository.archive.path |
...