Node Data Page In Component Access Group Problem
Hello,
I am trying to centralize the service integrations on our platform that nearly has 50 applications.
The solution is to have the integrations in components, but in this solution I am not able to give our common layer application's access group to Node scoped Data Pages. I thought having my common layer application as built on for component would avoid such issue. But it did not let me save with that configuration.
When I tried to remove my common layer application from component built on area and add the component under my common layer application definition, I was able to save the access group set as it's. Removing it from application definition after the save is also tried but causes data page being unable to see the request data transform.
The reason we are not into putting these components in our common layer application definition is, we are taking full packages for every sprint and the size is being effected in respectable amounts since these components have thousands of rules in them.
Since these data pages will have service requests, we should use a commonly shared access group for them.
What would be the best solution?
ai4process ltd
GB
Softtech
TR
@RaviChandra thanks for the options, I wanted to proceed with option 1. But in here we have a problem such as our Integration Shell Application not being able to see the rules that are in the applications that use the Data Page. For making it clear, some applications require customizing the request and response data transforms regarding their needs. But it still uses the data transform from the Component.
How could we solve this issue?
ai4process ltd
GB
To maintain a loosely coupled architecture and avoid direct dependencies between the calling application and the service integration components, consider using JSON-based serialization and deserialization for both request and response handling.
-
Request Handling: Pass the incoming request as a JSON string (e.g.,
requestJSON) to the Node-level Data Page. Within the Data Page, use a dedicated JSON Data Transform to deserialize this string and populate the HTTP request structure dynamically. This allows each consuming application to format its request independently while still leveraging the shared integration logic. -
Response Handling: After the service call, serialize the response into a single JSON string parameter. The calling application can then use its own JSON Data Transform to convert this string back into a structured page for further processing.
HCA Healthcare
US
@MustafaE Node data pages run with the access group you set on them, so they only see rules in that app stack. Put all integration components into a small Integration Shell application built on your common layer, and point the node data pages’ access group to that shell app. Keep the node pages generic: accept a requestJSON string and return a responseJSON string. Each consuming app does its own request and response mapping in its own rules before and after the call, so you avoid needing app-specific overrides inside the node page. If you truly need shared extension points, add a single Extensions ruleset to the shell app and to every consuming app, and pick variants by an app or tenant parameter. Another option is using requestor pools with an access group that includes both the shell and component rulesets. Avoid removing the component from built-on just to save; instead package components separately to keep sprint packages lean. If performance allows, you can move only the mapping pages to thread scope and keep the connector call node-scoped.
@MustafaE
Node-level Data Pages require a valid access group to resolve rules. When the component doesn’t inherit the common layer application directly (via
Built on), the access group loses visibility into those rules—even if temporarily added.Below are few options -
#1: Use a Shared Integration Application
Create a lightweight “Integration Shell” application that includes all components and is built on the common layer. Assign Node-level Data Pages to an access group tied to this shell app. This avoids bloating the common layer while preserving rule resolution.
#2: Use Requestor Pools with Explicit Access Groups
For service-level Data Pages, configure requestor pools with access groups that include both the common layer and component apps. This ensures runtime resolution without modifying app definitions.
Note: If you're using Deployment Manager or pipelines, you can automate component packaging separately and link them via manifest files, keeping your sprint packages lightweight