Configuring Providers

Providers configuration table can be accessed via Edit Driver/Plugin Options action of the Distributed Architecture plugin's global configuration context.

Providers are incoming and outgoing connections to remote platform servers whose selected contexts and context sub-trees will be attached to the context tree of the local server. Local modules and contexts of your app will be able to transparently interact with these remote contexts just like if they were local contexts.

Every provider has the following properties:

• Enabled. Enables or disables the provider. Disabled outgoing providers don't connect to provider servers. Disabled incoming providers don't accept connections from provider servers.

• Name. The unique name of provider. It also acts as the name of provider’s mounted root context on this server. Name must follow context naming conventions. For example, if a provider’s name is “edgeA” it’s remote root context will be locally available using the “mount.edgeA” context path.

• Connection Type. For an Incoming connection type, the local server awaits and accepts network connections from a remote provider server. For an Outgoing connection type, the local server establishes its own network connection to the remote provider server.

• Server Address. Address of primary (or the only) remote provider server. Available for Outgoing provider connections only.

• Failover Server Address. Address of failover provider server to be used if the primary server is unreachable. If established, connection to the failover server will be maintained until it’s unreachable. If both primary and failover servers are unreachable, server will periodically attempt to establish a connection to both. Optional and available for Outgoing provider connections only.

• Port. Port number on provider server to connect to. Valid for Outgoing provider connections.

• Username. Name of a user account on the remote provider server to use for authentication and authorization on this server. Access to all contexts of the provider server using this connection will be performed under the permissions of this user.

• Password. Password for the user account.

• Certificate Trust Policy. Defines how to verify certificates provided via an SSL/TLS connection.

• Certificate. Alias of an SSL/TLS certificate to use for authentication. The certificate with that alias must exist in the server's client certificate storage.

• Mount Points. The list of remote provider server’s context sub-trees or individual contexts that will be attached to the local server’s context tree. Properties of a mount point are described below.

• Variable Filter Expression. If defined, this expression will be evaluated for each row in value of remote server’s Variables variable. If it returns false, the remote variable will not be added to the local proxy context of remote provider server’s context.

• Propagate Unified Search Requests. If enabled, any unified search request launched on this server or received from another server will be forwarded to the provider server. Collected search results will be added to the local search results.

• Don’t Save Help Data. Prevents variable field help texts found in provider server variable definitions to be transferred to local variable definitions. This setting should only be enabled under extreme memory limitations of this consumer server.

• Name. This local name of remote provider server’s context subtree root context. It may differ from this context’s name on the remote server. Name must follow context naming conventions.

• Local Path (Mount Point). Path of a local context that will act as a "mount point" for contexts imported from the provider server. This is the path on local consumer server. A proxy context of the root context of remote context sub-tree will be added as a child to this local context. Name of the local child context is specified by the Name parameter.

• Remote Path (Root Node of Imported Context Subtree). Path of the root context of context sub-tree what will be imported from provider server. This is a path on the remote provider server.

It's important to understand the difference between "real" and "mapped" container contexts before specifying a Remote Path. See Visible and Real Context Trees for more details.

Imagine that provider server has the following contexts:

A

A.B

A.B.C1

A.B.C2

The consumer server wants to import context sub-tree rooted at A.B. The imported sub-tree should be connected at path X.Y of the provider context.

For the above setup, we can use the following Mount Point configuration options:

• Name: P

• Local Path: X.Y

• Remote Path: A.B

Once the consumer-provider connection is established and import operation succeed, we'll get the following relations between paths of contexts:

It may seem more logical that paths on consumer server should start from X.Y.B. However, the name of root imported context is substituted by provider name (i.e. B substituted by P). This is necessary to avoid name duplication. For example, the consumer server has "admin" context in "users", and we want to import "admin" context from provider server by using "users" as a mount point. We can name the provider "provider_admin" and, thus, the path of root imported context on consumer server will be "users.provider_admin". The root context name substitution also helps to import remote root context (whose context path equals to empty string).

This example explains how to connect a user of a remote server to a local server's Users container to make remote user acting as a local one. In this case the consumer server (one that will host the remote user) will connect to the provider server itself in a classic way (like a client connects to a server).

To configure the described use case, add the following record to the Providers table on the consumer server:

Was this page helpful?

Tell us more

Send

Thank you!