...
...
...
...
...
...
...
...
...
...
Figure 1: Clustering Architecture
...
This section describes the Adeptia Suite components – Kernel, WebRunner, Back-end database, Log database, and Repository.
Kernel
Kernel is a runtime run time environment of Adeptia Suite. It handles all the execution jobs, for e.g., the jobs that are executing. For example, execution of Process Flows, Scheduling of Events, Queue Processing, and Process flow Recoveries.
Kernel in Clustering mode (for information on Clustering, refer to Clustering Deployment Guide)
When you enable clustering, the execution of process flows flow is distributed among Kernels of each instance of Adeptia Suite server. All the execution requests first go to the Primary Node. The Primary Node then , which in turn, distributes the execution jobs among all other kernels. It is the Primary Node, which manages Scheduling of Events and Queue Processing. If any node goes down, the Primary Node identifies the process flows, which are flow (running on that node), recovers them, and again distributes the execution among the available nodes.
...
WebRunner
WebRunner handles all the user's requests such as creating, editing, and deleting of activities through GUI.
WebRunner in Clustering mode
When you enable clustering in Adeptia Suite, it is enabled only for Kernel, and not for WebRunner. If you also want to load balance the GUI requests, you can use an external load balancer for WebRunners (see Figure 1 ). Make sure that the WebRunner runs on all the nodes. Secure Bridge and Secure Engine users must always use an external load balancer.
Shared Location for all the Nodes
...
Databases
Adeptia Suite requires two types of databases, namely, Back-end database and Log database.
Back-end database
A backBack-end database is used to store the objects. All the activities (i.e. Process flows, activities, users, etc.and more) created through the GUI are stored in the backend back-end database. By default, Adeptia Suite uses HSQLDB (which is an embedded database) as backend. a back-end database.
Back-end database in Clustering mode
While setting up a clustered environment:
- All the nodes of the cluster should must use the same backendback-end database.
- Adeptia Suite does not provide Clustering or Failover Fail-over setup for the databases, however, you can set that up 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 maintains maintain logs of all the design time and run time activities that you run within Adeptia Suite. For example, Process flow log, event log, etcand more. Adeptia Suite writes all these logs into to the log database.
Log database in Clustering mode
While setting up a clustered environment:
- 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).
Anchor Shared_Locationn Shared_Locationn
Shared Location
| Shared_Locationn | |
| Shared_Locationn |
Adeptia Suite stores intermediate data to be used throughout the process flow execution. 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 can be accessed by all the nodes of a cluster. Depending on your operating system, you may use any of the File Sharing services. Some of the popular options include NFS, Samba / CIFS, and SSHFS.
The intermediate data is stored in the following folders:
Repository Folder
When the process flow is executed, data from the source is converted to the an intermediate form and then it is 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 to this folder.
Recovery 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.
Rerun Folder
The process flows may also be aborted due to any other reason e.g.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 and should be shared among all the nodes of the cluster.
Others
When applicable, the following additional folders must also be shared among 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 |
| Anchor | ||||
|---|---|---|---|---|
|