Snaplogic Triggered Task using an OnPremises URL through Load Balanced Groundplex Nodes

[dshen]

This article describes how a triggered task is invoked in the SnapLogic Elastic Integration
Platform using an OnPremise URL through load balanced Groundplex nodes.

Assume that your organization has a SnapLogic Groundplex provisioned with 3 nodes. When an OnPremise URL is exposed for a triggered task, it will automatically suggest the hostname of one of the nodes that belongs to the Groundplex.

e.g., https://GP-Node1:<port>/api/1/rest/feed/<RELATIVE_PATH_TO_TASK>/

To provide redundancy across all nodes in the Groundplex when a triggered task is invoked, a load balancer can be placed in front of the Groundplex nodes. When a load balancer is setup and configured, Snaplogic will use the load balancer in the auto-generated OnPremise URL.

e.g., https://GP-LB:<PORT>/api/1/rest/feed/<RELATIVE_PATH_TO_TASK>/

The following diagram describes the flow of network requests made when remotely executing a triggered task using a load balancer OnPremise URL.

1. A remote client invokes the triggered task using the OnPremise URL that points to the load balancer (e.g., GP-LB).
2. The load balancer forwards the request to an active groundplex node. GP-Node1 is selected for the purpose of this example.
3. The groundplex node that receives the triggered task request asks the Control Plane on which node the task should be executed.
4. The Control Plane forwards the request to an active groundplex node. GP-Node2 is selected for the purpose of this example.
5. The triggered task now prepares to be executed on GP-Node2. An HTTPS connection is created between GPNode-1 and GP-Node2 to enable data to be streamed between the nodes.
6. The data is read/write from/to the end points.
7. The response message is sent though GP-Node1 then GP-LB (load balancer) back to the caller.

[sanjaynayak]

Thanks @cjhoward18 for the info, correct me this flow if my understanding is correct due to cache and we have two cases.

2. The load balancer forwards the request to an active groundplex node. GP-Node1 is
   selected for the purpose of this example.

Case1:

In this case if task is already cached in GP-Node1, it will execute the task and will sent response back to GP-LB and request will not go to control plane at all.

Case2:
in case task is not cached then request will go from GP-Node1 to control plane and control plane will not decide as you mentioned which node is going to be execute the task, it must be the same node (GP-Node1), from where request goes to control plane.

is there anyway we can check task is cached previously or not before execution?

[cjhoward18]

No, there is no way to check before execution.

Is there a use case or problem to be solved that you could shed some light on at a high level?

[sanjaynayak]

@cjhoward18 thanks, Load balance flow is working as we discussed, will update the above flow chart. Related to cache, one of the case was like, newly crated account was not working, we had to restart the node, it was different cause and not related to Load balance, it was node property parameter jvm key related. will create a separate page for this.

But coming to our load balance cache case: Lets assume below.

1- Trigger task ran first time, it will keep the asset in node1.
2- Assume we modified the asset and it got saved in control plane.
3 - Trigger task ran 2nd time, will it pick up the updated asset or already cached one.
In this case if updated one, then there is no need to restart the node.
It will help us in automation.

[cjhoward18]

Hi,

Updating an asset does not require a restart for the asset updates to take effect.

[sanjaynayak]

Perfect @cjhoward18