Configure Gateway
- Last UpdatedJun 10, 2024
- 8 minute read
After you set up the Initial Gateway, you must configure it. This includes adding credentials for access to Workflow Server which is the first level of authentication.
Prerequisites:
-
Before provisioning a repository, make sure you configure Galaxy security to any of the valid choices. Do not change the Galaxy security after provisioning.
-
After you configure the Gateway Object and use it for creating events, do not change its name.
To configure the Gateway
-
Double-click the instance that you created while setting up the initial gateway.
For example, double-click WorkflowGateway_001 in the Deployment section.
-
In the Gateway Configuration tab that opens, enter the values for the following fields:
-
Unique Environment Name: The server is capable of communicating with multiple Galaxies in a single process. In a multi-Galaxy environment, you cannot ensure the uniqueness of the Galaxy name. An Unique Environment Name is used as work around for this.
In an environment with a single Galaxy, or multiple Galaxies with unique names, the Unique Environment Name can be the same as the Galaxy name.
In an environment with multiple Galaxies where different Galaxy environments share the same name, each separate Galaxy environment needs to be provided with an unique name while connecting to the server. An unique name is required to avoid naming conflicts.
By default, in the Unique Environment Name field, the Galaxy name is populated. You can edit this once at the beginning. However, once configured and saved, the Unique Environment Name field becomes read-only. -
Passphrase: The passphrase to configure Cryptography Settings and use the encryption algorithm in the product. Click Import to import the saved cryptography settings.
Note:
- When you provision the Gateway object to multiple AVEVA Work Task Servers, provide the same Passphrase settings on all the AVEVA Work Tasks Servers.
- The passphrase value should have characters between 8 and 20, consisting of lowercase, uppercase, number, and special characters. -
Server Address: Address of the server.
-
Authentication User Domain: User domain of the server. The domain name is case sensitive.
-
Authentication User Id: User ID of the server.
Authentication User Password: Password for the user name of the server.

-
-
Click Test Connection to verify the authentication.
-
If Test Connection is successful, the Repository Name field is populated with the available repositories.
-
If authentication is not successful, verify the credentials. If authentication is not successful consistently, contact the network administrator to ensure that the user credentials provided are part of the Administrators, SkeltaAdmins, or the SkeltaRemoteUsers roles, and there are no communication issues between the machines. Also, the SkeltaAdmins or SkeltaRemoteUsers roles need to be manually created.
-
-
In the Repository Name field, select the workflow repository to connect to. The Provision window appears.
-
Add credentials to access the workflow repository which is the second level of authentication. To authorize and provision access of and mapping to the workflow repository, perform the following steps:
Workflow Repository Authentication Info
-
In the Providers field, select Active Directory or AVEVA Work Tasks List based on the provider for which the workflow repository is created.
-
Enter the user name and password details based on the user provider. For the default user name and password, contact the technical support team or refer the Get Started Guide in the ISO file of AVEVA Work Tasks.
The user must have administrator rights on the workflow repository.
-
Select Use AD Provider same as Repository to leverage Active Directory users instead of Galaxy users.

-
-
For Inbound Connection Authentication Info, enter the credentials of GR Node in the Authentication User Domain, Authentication User Id, and Authentication User Password fields.
Note: The Authentication User Domain is case sensitive and must be provided in proper case.
-
Click Authorize & Provision.
The repository is now provisioned to be connected to the Galaxy. The repository and galaxy are now connected.
The Use Active Directory Service Provision check box appears only if all the following conditions are satisfied:
-
The Galaxy User security is Operating System user or Operating System group.
-
The repository to provision is created using the Active Directory authentication.
-
The Galaxy user and repository user domain are same.
On provisioning, the users in Galaxy are available to the workflow after creating a user provider for the Galaxy.
Galaxy users can log on to the Enterprise Console as ArchestrA Users after provisioning and deploying the gateway object to a workflow repository. If the users log on before provisioning and deploying the gateway object, the following message appears:
After deploying the gateway object, if the security mode in the galaxy has been changed, then the workflow gateway object needs to redeployed.
The following activities take place during provisioning:
-
The logged in user is added as administrator in the workflow repository based on the user authentication provided during provisioning. This is done only if the user is an administrator in the workflow repository.
-
Galaxy information is stored in AVEVA Work Tasks using tables and lists. The Galaxy users are synchronized to the workflow repository.
-
Enabling a new user provider to map the Galaxy users to the repository allows the Galaxy users to be a part of the AVEVA Work Tasks workflow activities.
-
The Galaxy users can also access the AVEVA Work Tasks functionalities, such as Inbox, Forms, Business Activity Monitoring (BAM), Process Designer.
The details that you enter in the Inbound Connection Info tab is the same as the General inbound tab as shown in the following image:

Unprovisioning a Provisioned Workflow Repository
You can unprovision a provisioned workflow repository. Unprovisioning is an option of the workflow gateway object to roll back the changes done to the workflow repository. While unprovisioning, the workflow and associations created during provisioning the workflow repository, are not deleted.
While moving the workflow repository database from one environment to another environment, you must unprovision the workflow repository.
To unprovision a provisioned workflow repository, complete the following steps:
-
Open the derived template or instance of the workflow gateway object.
-
Click Test Connection to validate the connection.
-
Select the provisioned repository from list of available repositories in the Repository Name field.
The Provision dialog box appears.
-
Click Un Provision.
Using the Advanced Tabs
Advanced tabs are available for Inbound and Outbound Connection settings, for more control on the Gateway configuration.
Outbound Connection Info: Advanced Options
The following image shows the fields of the Outbound Connection Info tab.

The Outbound Connection Info tab contains the following fields:
-
Outbound Connector Port: This field can be edited after you provision the workflow repository for the Galaxy.
-
Outbound Connector Binding: Binding protocol for the connection, preferably used when Workflow Server is within the same network. Choose from the following options:
-
TCP: Default binding protocol for the connection, preferably used when Workflow Server is within the same network.
-
HTTPS: Secure connectivity over the Internet.
-
-
Operation Timeout: Time period after which the request made to the Workflow server does end if not connected.
-
Connection Life Time: The duration for which the of the connection between the Galaxy and the Workflow Server lasts.
-
User Provider Name: Repository user provider, either Active Directory or Skelta List.
-
Theme: Theme of the repository.
-
Enterprise Console Site URL: The URL used to access the workflow repository from the Workflow Server.
-
Repository Auth User Id: Captured during and displayed during provisioning.
-
Repository Auth User Password: Captured during provisioning.
Inbound Connection Info: Advanced Options
The following image shows the fields of the Inbound Connection Info tab.

The Inbound Connection Info tab contains the following fields:
-
Inbound Connector Host: Default runtime node where the Gateway object is deployed.
-
Inbound Connector Port: Connection Port by AVEVA Work Tasks to fetch any data from Galaxy.
-
Inbound Connector Binding: Binding protocol for the connection, preferably used when Workflow Server is within the same network. Choose from the following options:
-
TCP: Default binding protocol for the connection, preferably used when Workflow Server is within the same network.
-
HTTPS. Secure connectivity over the Internet.
-
-
Operation Timeout: Time period after which the request made from the Workflow server to the Galaxy will end, if not connected.
-
Connection Life Time: Time period that the connection will last between the Workflow Server and the Galaxy.
-
Throttling, Max Concurrent Calls: Connector service properties, the maximum number of messages that can actively be processed. Each client channel can have one pending message that does not count against this total until the service begins to process it. Increase this value if you want your service to process a larger message load.
-
Throttling, Max Concurrent Instances: Connector service properties, the maximum number of InstanceContext objects in a service that can be executed in a single instance.
-
Throttling, Max Concurrent Sessions: The maximum number of sessions that a service can accept at one time.
Sync Security Info: Advanced Options
Use this tab to synchronize users, roles, and security groups to the Workflow Server. Set the refresh interval for automatic synchronization in a specific time-frame. To synchronize, click Synchronize.
After changing the Advanced options, you save the object. You can now access the Enterprise Console functionality from the Workflow Toolbox.

Note:
- In a scenario where a derived template of workflow gateway object is provisioned
with a workflow repository, one instance of the Gateway Object is deployed in the
GR Platform and another instance deployed in the Boot Platform. If the inbound connector
host name is changed the ArchestrA Read/Write activity will not work.
- The user, which is set as Change Network Account needs to be mapped to the Administrators group in order to avoid SkeltaConnectorClientArchestrA
service installation/uninstallation during deploy/undeploy of Workflow Gateway Object.
- To set up the zoom level, refer to Setting Zoom for the Web Browser Control in System Platform and InTouch.
- To lookup/search the user from Galaxy User's provider, search with Galaxy User Name search filter, instead of Galaxy User Full Name search filter.
- When the user is searched based on the All Providers search filter, the user name from different providers is listed in a single line
separated by comma, and the user from all providers may not be assigned the work item.
Hence, it is good to use separate providers to search the user and assign the work
item. .