How CIP7 Works | Rinami Knowledge Garden

The diagram below shows how a typical CIP7 deployment is structured, from a device or application through to JD Edwards EnterpriseOne. The customer infrastructure shown on the right is an example of a customer-managed architecture. Actual deployments will vary depending on the organisation's network setup, security requirements, and JDE environment configuration.

All inbound traffic passes through Google Cloud Armor and a Cloud Load Balancer before reaching the Access Service and Cantara API Gateway, each operating from a static outbound IP pool. On the customer side, traffic passes through the Customer Firewall within the DMZ, then through an Internal Firewall before reaching the CIP7 Agent Tier and JDE server environment. Authentication is handled separately via OAuth2 / SAML2 between the device and the customer's identity provider.

image (38).png — *Figure 1 - CIP7 architecture overview. Cantara Cloud (left) and example customer-managed infrastructure (right).*

A few things worth noting:

Regional deployments - CIP7 is currently available across three regions; United States, Belgium, and Australia. Customers choose the region that meets their data-sovereignty requirements.
Static outbound IPs - Each region operates from a known IP pool, making Customer Firewall whitelisting straightforward and predictable.
CIP7 Agents - CIP7 Agents are lightweight software components deployed within the customer network. The recommended approach is to co-locate the agent on the same VM as the AIS Server, but agents can be deployed separately if needed. Multiple agents can be deployed as required.