Administrator > Secure Agent services > Process Server
  

Process Server

Process Server is the Secure Agent service that executes Application Integration processes, connectors, and connections.
When you deploy Application Integration assets to the Secure Agent, you deploy them to Process Server. When you run an asset, Process Server executes it.
The PostgreSQL database comes with the Process Server service of the Secure Agent and stores the metadata that Process Server collects and generates.
Find the PostgreSQL directory at the following location on your system:
<Secure Agent installation directory>\apps\process-engine\data\PostGreSql

Process Server properties

To change or optimize the behavior of Process Server, configure Process Server properties. You can configure the server, Secure Agent group, Java Virtual Machine, connector, database, and logging properties.
The following image shows some Process Server properties:
You can configure the following server properties:
Name
Communication Method
Description
host-name
Secure Agent Channel
The host name of the Process Engine server.
shutdown-port
Secure Agent Channel
Process Server Tomcat shutdown port.
key-alias
HTTPS
The identifier of the keystore record that contains security keys for HTTPS communication.
key-store
HTTPS
The path and file name of the key store file that Application Integration uses for HTTPS communication.
When you install the Secure Agent, you can find the key store in the following default location:
<Secure Agent installation directory>/apps/process-engine/conf/ae.keystore
You can also enter a relative path. For example, if the current working directory is the Secure Agent installation directory, enter the following value to point to the ae.keystore file:
../conf/ae.keystore
Note: The file path can contain only forward slashes (/).
key-store-password
HTTPS
The key store password. The default password is password.
trust-store
HTTPS
The path and file name of the trust store file that Application Integration uses for HTTPS communication.
When you install the Secure Agent, you can find the trust store in the default location:
<Secure Agent installation directory>/apps/process-engine/conf/ae.cacerts
You can also enter a relative path. For example, if the current working directory is the Secure Agent installation directory, enter the following value to point to the ae.cacerts file:
../conf/ae.cacerts
Note: The file path can contain only forward slashes (/).
If you want to import public certificates for service endpoint authentication, place them in the following location:
<Secure Agent installation directory>/apps/process-engine/conf/certs
trust-store-password
HTTPS
The trust store password. The default password is changeit. You can change the password.
ldap-enabled-realm
HTTP/HTTPS
Set this property to True if you want to use an LDAP provider for authentication. Use the LDAP provider as a centralized form of authentication when you have clustered Secure Agents.
ldap-properties
HTTP/HTTPS
The LDAP properties that you need to configure. Edit the existing properties to suit your LDAP provider.
Note: Your LDAP password does not appear on screen. The value of $(pe.ldap.password) is taken from the PE_LDAP_PASSWORD environment variable
ssl-enabled-protocols
HTTPS
The TLS protocol to use. The default protocol, TLSv1.2, is the most secure protocol. Change this value to an older version like TLSv1.0 or TLSv1.1 only if you face compatibility issues
ephemeral-DH-key-size
HTTPS
The key length of the secure algorithm. The default value is 2048. Change this value only if you face compatibility issues.
use-secure-ciphers-only
HTTPS
Limits the set of ciphers used during a call to the endpoint to secure ciphers only. The default value is True. Change this value to false only if you face compatibility issues.
You can configure the following Secure Agent group ('cluster' on the UI) properties:
Name
Communication Method
Description
name
HTTP/HTTPS
The name of the Secure Agent group.
primary-node
HTTP/HTTPS
Set this property to true if you want the Secure Agent to be the master agent. When you select a master agent, you create a Secure Agent cluster. In a cluster, all Secure Agents share the postgreSQL database of the master Secure Agent.
load-balance-url
HTTP/HTTPS
The load balancer URL that you can use to invoke the process deployed to the Secure Agent.
Applicable if you have a load balancer.
You can configure the following Java Virtual Machine properties:
Name
Communication Method
Description
min-heap
Secure Agent Channel
The minimum heap memory that Process Server allocates to the Tomcat JVM.
max-heap
Secure Agent Channel
The maximum heap memory that Process Server allocates to the Tomcat JVM.
additional-properties
Secure Agent Channel
A custom system property that you can add to the Tomcat JVM set. For example, you can set the custom property -Dsun.net.inetaddr.ttl=60
You can configure the following connector properties:
Name
Communication Method
Description
http-port
HTTP
The HTTP port to which the Secure Agent sends data. The default port is 7080.
For more information about the construction of REST and SOAP endpoint URLs, see the Application Integration help.
http-maxThreads
HTTP
The maximum number of connections that Process Server creates with Application Integration over HTTP.
http-connectionTimeout
HTTP
The maximum time, in milliseconds, that Process Server waits for an HTTP connection to reply.
https-port
HTTPS
The HTTPS port to which the Secure Agent sends data. The default port is 7443.
For more information about the construction of REST and SOAP endpoint URLs, see the Application Integration help.
https-maxThreads
HTTPS
The maximum number of connections that Process Server creates with Application Integration over HTTPS.
https-connectionTimeout
HTTPS
The maximum time, in milliseconds, that Process Server waits for an HTTPS connection to reply.
secure-channel maxThreads
Secure Agent Channel
The maximum number of connections that Process Server creates with Application Integration.
secure-channel-connectionTimeout
Secure Agent Channel
The maximum time, in milliseconds, that Process Server waits for a connection to reply.
You can configure the following database properties:
Name
Communication Method
Description
type
Secure Agent Channel
The database type that Process Server runs on.
Important: Do not change this setting. The Application Integration Secure Agent does not support other databases.
driver
Secure Agent Channel
The database driver that Process Server runs on.
Important: Do not change this setting. The Informatica Cloud Secure Agent does not support other databases.
URL
Secure Agent Channel
URL at which Process Server accesses the database.
Important: Do not change this setting. The Informatica Cloud Secure Agent does not support other databases.
maxActive
Secure Agent Channel
The maximum number of active connections allocated to Process Server database at the same time.
maxIdle
Secure Agent Channel
The maximum number of connections that can remain idle at a time in the database. Process Server releases connections if the number of idle connections crosses this number.
maxWait
Secure Agent Channel
The maximum time that the database waits for a connection if none are available.
connection-properties
Secure Agent Channel
Key-value pairs of database connection properties. Some keys are available by default.
Do not delete the default keys. You can, however, change the values of these keys.
You can add other key-value pairs. For example, you can add the following key-value pair:
key: autoReconnect
value: true
You can configure the following logging properties:
Name
Communication Method
Description
1catalina_org_apache_juli_FileHandler_level
Secure Agent Channel
The level of logging in the file:
< Secure Agent installation directory>\apps\process-engine\logs\catalina.log.
Default: FINE
2localhost_org_apache_juli_FileHandler_level
Secure Agent Channel
The level of logging in the file:
< Secure Agent installation directory>\apps\process-engine\logs\localhost.log.
Default: FINE
3manager_org_apache_juli_FileHandler_level
Secure Agent Channel
The level of logging in the file:
< Secure Agent installation directory>\apps\process-engine\logs\manager.log.
Default: FINE
4host_manager_org_apache_juli_FileHandler_level
Secure Agent Channel
The level of logging in the file:
< Secure Agent installation directory>\apps\process-engine\logs\host-manager.log.
Default: FINE
java_util_logging_ConsoleHandler_level
Secure Agent Channel
The level of logging in the CMD window that appears when you start Tomcat.
Default: FINE
org_apache_catalina_core_ContainerBase_Catalina_localhost_level
Secure Agent Channel
The level of logging in the localhost.log file when you host Tomcat on a virtual machine.
Default: INFO
org_apache_catalina_core_ContainerBase_Catalina_localhost_manager_level
Secure Agent Channel
The level of logging in the manager.log file when you host Tomcat on a virtual machine.
Default: INFO
org_apache_catalina_core_ContainerBase_Catalina_localhost_host-manager_level
Secure Agent Channel
The level of logging in the host-manager.log file when you host Tomcat on a virtual machine.
Default: INFO

Default connection database properties

The following table describes the default keys that are available for the connection-properties database property:
Key
Description
timeBetweenEvictionRuns
The number of milliseconds that Process Server waits in-between runs of the idle object evictor thread.
testOnBorrow value
Process Server validates objects before borrowing objects from the pool. If Process Server cannot validate the object, it drops the object from the pool. Then, Process Server tries to borrow another object.
testWhileIdle
Process Server validates objects by the idle object evictor (if one exists). If Process Server cannot validate the object, it drops the object from the pool.
validationQuery value
The SQL query that validates connections from this pool before returning them to the caller. If you specify this property, the query must be an SQL SELECT statement that returns at least one row.

Logging levels

The following table describes the levels that you can configure for Process Server logging properties:
Level
Description
SEVERE
Logs errors.
WARNING
Logs potentially harmful situations.
INFO
Logs informational events that show the high-level progress of the application.
CONFIG
Logs informational events in more detail than at the INFO level.
FINE
Logs fine-grained informational events that you can use to debug an application.
FINER
Logs fine-grained informational events in more detail than at the FINE level.
FINEST
Logs all events.

Process Server sizing recommendations

Configure the Process Server service of the Secure Agent according to your workload.
Use the following sizing recommendations to optimize resources:
Recommendation
Small
Medium
Large
Process Count
75
175
350
Resource Cache (MB)
75
175
350
Work Manager Thread Pool Min
50
100
150
Work Manager Thread Pool Max
250
500
750
JVM Min Heap (MB)
Default
768
1024
JVM Max Heap (MB)
Default
Default
4096
The default JVM Min Heap is 512 MB, and the default JVM Max Heap is 1536 MB.
To configure the Process Count, Resources Cache, Work Manager Thread Pool Min, and Work Manager Thread Pool Max, go to the Server Configuration section of the Application Integration Console service.
When you start the Process Server on UNIX operating systems, you might receive the following error:
Cannot write to temp location [/tmp]
This error occurs because UNIX limits the number of files that can be created by a single process. The maximum number of files that can be created by a single process is 1024.
To avoid this error, Informatica recommends that you increase the open files limit to atleast 10 times the default value of 1024. Contact your system administrator to increase the value of any other relevant parameters such as max user processes.
For more information about Process Server sizing for a Secure Agent, see the following document:
https://network.informatica.com/docs/DOC-17439

Communication with the Secure Agent

Informatica Intelligent Cloud Services sends data from the Secure Agent to the Process Server through the Secure Agent Channel or a through a direct HTTP or HTTPS link.
The Secure Agent communicates with Process Server in two ways:
The Secure Agent Channel
A secure channel that creates tunnels between each connected Secure Agent and Process Server.
HTTP or HTTPS
A protocol over which the Secure Agent directly sends data to Process Server. If you use this communication method, Informatica Intelligent Cloud Services validates your credentials against the authentication provider.
For more information on the communication method that each Process Server property uses, see the Process Server Properties.
The following image shows the two methods of communication between the Secure Agent and Process Server:
The Data Integration Server, Process Server, Secure Agent Core, and Secure Agent Manager communicate with the Secure Agent through the Secure Agent Channel or through HTTP/HTTPS.

Secure Agent configurations for Process Server

Deploy an asset to a single Secure Agent, a Secure Agent group, or a Secure Agent cluster based on your business needs.
When you deploy Application Integration processes, connections, or service connectors to a Secure Agent, you deploy the assets to the Process Server service of the Secure Agent. All Secure Agents with the Process Server service use a PostgreSQL database.
You can deploy an asset to the following Secure Agent configurations:
Single Secure Agent
A single Secure Agent might be the only agent in a group, or one of many agents on a group.
For more information, see Deploy to a Single Secure Agent.
Secure Agent group
A Secure Agent group contain multiple agents. When you deploy an asset to a Secure Agent group, Informatica Intelligent Cloud Services performs load balancing. Use the Secure Agent group configuration to distribute requests if you process stateless requests or use the Secure Agent only to serve OData requests.
For more information, see Deploy to a Secure Agent Group.
Secure Agent Cluster
A Secure Agent Cluster is an agent group that has a master securer agent. Use the Secure Agent Cluster configuration when you want all Process Servers to receive information about process execution activity.
For more information, see Deploy to a Secure Agent Cluster.
The following table summarizes the process execution of the Secure Agent in different scenarios:
Single Secure Agent
Secure Agent Group
Secure Agent Cluster
Agent Available
Process executes.
Process executes.
Process executes.
Agent Unavailable
Process does not execute.
Process executes on any available Secure Agent.
Process executes on any available Secure Agent.
Agent Stops Mid-Execution
Process does not execute.
Process stops when the Secure Agent stops.
Process continues to execute on another Secure Agent.

Deploy to a single Secure Agent

You can deploy an asset directly to one agent in a group.
When you deploy an asset to a single Secure Agent, no other Process Server in the Secure Agent group receives the asset definitions.
The following image shows a sample configuration where process X is deployed directly to Secure Agent 1:
This figure shows process X deployed to Secure Agent 1. Secure Agent 1 is a part of Secure Agent group A, a group that contains two Secure Agents.
Only Secure Agent 1 can execute Process X. If Secure Agent 1 is unavailable, the process does not execute.

Deploy to a Secure Agent group

A Secure Agent group contains multiple agents. You can deploy an asset to a Secure Agent group.
Use the Secure Agent group configuration to distribute requests if you process stateless requests or use the Secure Agent only to serve OData requests.
In a Secure Agent group, Informatica Intelligent Cloud Services dispatches incoming requests to available Secure Agents in a round-robin manner.
When you deploy an asset to a Secure Agent group, you use a load balanced configuration. Informatica Intelligent Cloud Services performs the load balancing. You can also use a custom load balancer by setting the load-balance-url Process Server property. For more information, see Process Server Properties.
For more information about Secure Agent groups, see Secure Agent Groups with Multiple Agents.
All Secure Agents in a group use individual PostgreSQL databases. When you deploy an asset to a Secure Agent group, all Process Servers within the group receive details about new or updated asset definitions. However, the other Process Servers in the group do not receive details about the execution activity of an asset. For example, if a Secure Agent within the group fails during process execution, the process does not continue to execute on another Secure Agent within the group.
The following image shows a sample configuration where process X is deployed to Secure Agent group A:
This figure shows process X deployed to Secure Agent group A. Group A has three Secure Agents with individual PostgreSQL databases.
If you modify and re-publish process X, all three Secure Agents receive the updated definition. Any Secure Agent can execute the process.
For example, if the process is invoked and Secure Agent 1 and Secure Agent 2 are unavailable, the load balanced configuration ensures that Secure Agent 3 executes process X. However, Secure Agent 1 and Secure Agent 2 do not receive information about whether the process has faulted or completed successfully. If Secure Agent 3 stops while executing the process X, the process does not execute further.

Deploy to a Secure Agent Cluster

A Secure Agent Cluster is an agent group with a master Secure Agent. You can deploy an asset to a Secure Agent Cluster.
When you deploy an asset to a Secure Agent Cluster, all Process Servers receive information about process execution activity. The master Secure Agent receives information and informs the other Secure Agents. If a Secure Agent fails during process execution, the process continues to executes on another Secure Agent within the cluster.
All Process Servers in a cluster share the PostgreSQL database of the master agent.
To define the master Secure Agent, use the primary-node Process Server property. For more information, see Process Server Properties.
The following image shows a sample configuration where process X is deployed to Secure Agent Cluster A:
This figure shows process X deployed to Secure Agent cluster A. Cluster A has three Secure Agents, with Secure Agent 2 as the master. All Secure Agents in cluster A use PosgtreSQL database 2.
If Secure Agent 3 starts executing process X but stops midway, either Secure Agent 1 or Secure Agent 2 continues to execute the process.

Managing the PostgreSQL database on Windows

Use binaries and utility scripts to manage the PostgreSQL database.
Important: To manage the PostgreSQL database, you must log in as a user who does not have system administrator rights. A system administrator will be unable to run PostrgreSQL binaries and utility scripts.
Informatica has created some utility scripts based on PostgreSQL binaries. These utility scripts make it easier for you to manage the PostgreSQL database.
The following directories contain files for the PostgreSQL database:
For more information about PostgreSQL scripts, see the PostgreSQL help at https://www.postgresql.org/docs/current/static/index.html.
Some of the following sections contain sample commands that use these default values:

Backing up the PostgreSQL database on Windows

Use the script db_backup.bat to back up the PostgreSQL database.
To back up the PostgreSQL database, perform the following steps:
  1. 1Go to <Secure Agent installation directory>\apps\process-engine\data\db\util.
  2. 2Run the following command:
    3. db_backup.bat <dbusername> <dbpassword> <path to backup file along with name of backup file with a ".dump" extension>.
For example, the Secure Agent creates the backup file 'BackupFile1.dump' in the location C:\postgre\backup if you run the following command:
db_backup.bat bpeluser bpel "C:\postgre\backup\BackupFile1.dump",
.

Restoring the PostgreSQL database on Windows

Use the command db_restore.bat to restore the PostgreSQL database from a backup file.
To restore the PostgreSQL database file from a backup file, perform the following steps:
  1. 1Go to <Secure Agent installation directory>\apps\process-engine\data\db\util.
  2. 2Run the following command:
    3. db_restore.bat <dbusername> <dbpassword> <path to dump file>.
For example, you use the file BackupFile1.dump to restore the PostgreSQL database if you run the following command:
db_restore.bat bpeluser bpel "C:\postgre\backup\BackupFile1.dump",

Resetting the PostgreSQL database on Windows

Shut down the PostgreSQL database and then use the command db_reset.bat to reset it.
To reset the PostgreSQL database to its original state, perform the following steps:
  1. 1Go to <Secure Agent installation directory>\apps\process-engine\data\db\util
  2. 2To shut down the server, run the following command:
    3. server_stop.bat
  3. 3To reset the PostgreSQL database, run the following command:
    4. db_reset.bat

Starting the PostgreSQL server on Windows

To start the Process server on Windows, perform the following steps:
  1. 1Go to <Secure Agent installation directory>\apps\process-engine\data\db\util.
  2. 2Run the following script:
    3. server_start.bat.

Stopping the PostgreSQL server on Windows

To stop the PostgreSQL server on Windows, perform the following steps:
  1. 1Go to <Secure Agent installation directory>\apps\process-engine\data\db\util.
  2. 2Run the following script:
    3. server_stop.bat.

Getting the PostgreSQL server status on Windows

To get the status of the PostgreSQL server on Windows, perform the following steps:
  1. 1Go to <Secure Agent installation directory>\apps\process-engine\data\db\util.
  2. 2Run the following script:
    3. server_status.bat.

Vacuuming the PostgreSQL database on Windows

Vacuum the PostgreSQL database to delete obsolete tuples and gain space. You use the script db_maintenance.bat to vacuum the PostgreSQL database.
By default, the PostgreSQL database autovacuums. If you want to manually vacuum the database, perform the following steps:
  1. 1Go to <Secure Agent installation directory>\apps\process-engine\data\db\util.
  2. 2To vacuum the entire database, run the following command:
    3. db_maintenance.bat <dbusername> <dbpassword> vacuum
  3. 3To vacuum a single table, run the following command:
    4. db_maintenance.bat <dbusername> <dbpassword> vacuum <tablename>
For example, you vacuum the 'aeprocesslogdata' table if you run the following command:
db_maintenance.bat bpeluser bpel vacuum aeprocesslogdata

Reindexing the PostgreSQL database on Windows

Use the reindexing option to clean the index and free up space after you vacuum data on PostgreSQL. You use the script db_maintenance.bat to reindex the PostgreSQL database.
To reindex the PostgreSQL database, perform the following steps:
  1. 1Go to < Secure Agent installation directory>\apps\process-engine\data\db\util.
  2. 2To reindex the entire database, run the following command:
    3. db_maintenance.bat <dbusername> <dbpassword> reindex
  3. 3To reindex a single table, run the following command:
    4. db_maintenance.bat <dbusername> <dbpassword> reindex <tablename>
For example, you reindex the 'aeprocesslogdata' table if you run the following command:
db_maintenance.bat bpeluser bpel reindex aeprocesslogdata

Resetting transaction logs on Windows

If the PostgreSQL server does not start because of corruption of the control information, use the command pg_resetxlog.exe to reset the control information.
To reset the PostgreSQL database control information, perform the following steps:
  1. 1Go to <Secure Agent installation directory>\apps\process-engine\data\db\postgresql-windows-x64-binaries\pgsql\bin.
  2. 2Run the following command:
    3. pg_resetxlog.exe -D <path to postgreSQL data directory>
For example, you reset transactions logs in the 'Data' directory if you run the following command:
pg_resetxlog.exe -D "C:\postgre\apps\process-engine\data\PostGreSql\Data"

Managing the PostgreSQL database on Linux

Use binaries utility scripts to manage the PostgreSQL database.
Important: To manage the PostgreSQL database, you must log in as a user who does not have root access. A root user will be unable to run PostrgreSQL binaries and utility scripts.
Informatica has created some utility script based on PostgreSQL binaries. These utility scripts make it easier for you to manage the PostgreSQL database.
The following directories contain files for the PostgreSQL database:
For more information about PostgreSQL scripts, see the PostgreSQL help at https://www.postgresql.org/docs/current/static/index.html.
Some sections contain sample commands that use the following default values:

Backing up the PostgreSQL database on Linux

Use the script db_backup.sh to back up the PostgreSQL database.
To back up the PostgreSQL database, perform the following steps:
  1. 1Go to <Secure Agent installation directory>/apps/process-engine/data/db/util.
  2. 2Run the following command:
    3. db_backup.sh <dbusername> <dbpassword> <path to backup file along with name of backup file>.dump.
For example, the Secure Agent creates the backup file backupfile1.dump in the location /home/data/myfolder/ if you run the following command:
db_backup.sh bpeluser bpel "/home/data/myfolder/backupfile1.dump",

Restoring the PostgreSQL database on Linux

Use the script db_restore.sh to restore the PostgreSQL database from a backup file.
To restore the PostgreSQL database file from a backup file, perform the following steps:
  1. 1Go to <Secure Agent installation directory>/apps/process-engine/data/db/util.
  2. 2Run the following command:
    3. db_restore.sh <dbusername> <dbpassword> <path to dump file>.
For example, you use the file backupfile1.dump to restore the PostgreSQL database if you run the following command:
db_restore.sh bpeluser bpel "/home/data/myfolder/backupfile1.dump",

Resetting the PostgreSQL database on Linux

You first shut down the PostgreSQL database and then use the script db_reset.sh to reset it.
To reset the PostgreSQL database to its original state, perform the following steps:
  1. 1Go to <Secure Agent installation directory>/apps/process-engine/data/db/util
  2. 2To shut down the server, run the following script:
    3. server_stop.sh
  3. 3To reset the PostgreSQL database, run the following script:
    4. db_reset.sh

Starting the PostgreSQL server on Linux

To start the PostgreSQL Server, perform the following steps:
  1. 1Go to <Secure Agent installation directory>/apps/process-engine/data/db/util.
  2. 2Run the following script:
    3. server_start.sh.

Stopping the PostgreSQL server on Linux

To stop the PostgreSQL server, perform the following steps:
  1. 1Go to <Secure Agent installation directory>/apps/process-engine/data/db/util.
  2. 2Run the following script:
    3. server_stop.sh.

Getting the PostgreSQL server status on Linux

To get the status of the PostgreSQL server on Linux, perform the following steps:
  1. 1Go to <Secure Agent installation directory>/apps/process-engine/data/db/util.
  2. 2Run the following script:
    3. server_status.sh.

Vacuuming the PostgreSQL database on Linux

Vacuum the PostrgeSQL database to delete obsolete tuples and gain space. You use the script db_maintenance.sh to vacuum the PostgreSQL database.
By default, the PostgreSQL database auto vacuums. If you want to manually vacuum the database, perform the following steps:
  1. 1Go to <Secure Agent installation directory>/apps/process-engine/data/db/util.
  2. 2To vacuum the entire database, run the following command:
    3. db_maintenance <dbusername> <dbpassword> vacuum
  3. 3To vacuum a single table, run the following command:
    4. db_maintenance.sh <dbusername> <dbpassword> vacuum <tablename>
For example, you vacuum the 'aeprocesslogdata' table if you run the following command:
db_maintenance.sh bpeluser bpel vacuum aeprocesslogdata

Reindexing the PostgreSQL database on Linux

Use the reindexing option to clean the index and free up space after you vacuum data on PostgreSQL. You use the script db_maintenance.sh to reindex the PostgreSQL database.
To reindex the PostgreSQL database, perform the following steps:
  1. 1Go to <Secure Agent installation directory>/apps/process-engine/data/db/util.
  2. 2To reindex the entire database, run the following command:
    3. db_maintenance <dbusername> <dbpassword> reindex
  3. 3To reindex a single table, run the following command:
    4. db_maintenance.sh <dbusername> <dbpassword> reindex <tablename>
For example, you reindex the 'aeprocesslogdata' table if you run the following command:
db_maintenance.sh bpeluser bpel reindex aeprocesslogdata

Resetting transaction logs on Linux

If the PostgreSQL server does not start because of corruption to the control information, use the command pg_resetxlog to reset the control information.
To reset the control information of the PostgreSQL database, perform the following steps:
  1. 1Go to <Secure Agent installation directory>/apps/process-engine/data/db/postgresql-linux-x64-binaries/pgsql/bin .
  2. 2Run the following command:
    3. pg_resetxlog -D <path to postgreSQL data directory>
For example, you reset the transactions logs in the Data directory, if you run the following command:
pg_resetxlog -D "home/apps/process engine/data/PostGreSql/Data"