DMZ Secure Agent placement, SAP ACLs, and inbound CAI calls
A manufacturer is implementing CAI between cloud Salesforce, on-premises SAP ECC, and an on-premises IBM MQ cluster. The Secure Agent is installed on two Linux VMs in a DMZ. Corporate firewall rules allow the agents to make outbound TCP 443 connections to Informatica Cloud, but do not allow inbound connections from the cloud. SAP accepts traffic only from the DMZ subnet, and MQ accepts only a dedicated service account. The company also wants SAP to call a CAI REST endpoint for real-time address validation. The two agent VMs are in the same agent group, but the network team has not opened the second VM’s IP in the SAP ACL. During testing, a developer routes Salesforce calls through the agent and sees high latency. The program has 6 weeks before go-live and a change freeze on the DMZ firewall in 4 weeks.
1. Decide which connections should execute on the Secure Agent and which on the cloud server. Justify each choice and identify the network changes required.
Read the worked answer
SAP and MQ are on-premises and not reachable from Informatica Cloud, so their connections must execute on the Secure Agent in the DMZ. Salesforce is a cloud SaaS and should execute on the cloud server, not through the agent; routing it through the DMZ adds latency and consumes agent capacity without a network benefit. The SAP-initiated address-validation call is inbound to CAI; the cloud endpoint is not reachable from SAP under the current firewall, so this requires an on-premises listener or gateway co-located with the agent group, or an approved VPN or inbound path.
Network changes: open the second agent IP in the SAP ACL, allow both agents to reach MQ, and allow the gateway path from SAP to the DMZ listener. Do not open inbound internet access to the agents. The developer’s high-latency Salesforce test is a symptom of unnecessary agent routing, not a reason to add more agents.
2. Design for high availability of the agent tier and for SAP-initiated calls to CAI. What must be true before go-live, and what is the risk if the second agent IP is not opened?
Read the worked answer
Put both agents in one agent group and configure the on-premises connections to use that group. Active/active is preferable to active/passive if both VMs have the same packages, credentials, and network access; a passive node that is not patched is not real high availability. The SAP ACL must include both agent IPs, and MQ must permit both. For SAP-initiated calls, front the two gateways with a load balancer or a DNS name so SAP does not hard-code one VM.
Before go-live, test failover by stopping one agent during a process and confirming the group picks up new work; also verify long-running process and recovery behavior, because failover for new requests does not automatically recover an in-flight process pinned to a dead node. If the second IP is not opened, the group is effectively single-node: a maintenance window or VM failure becomes an outage, and failover tests will pass only by accident.
3. What credential and connection-property practices reduce operational risk in this topology?
Read the worked answer
Store SAP and MQ credentials in connection properties or a secrets-backed connection, not in process steps, scripts, or chat. Use a dedicated least-privilege service account for MQ and an SAP technical user restricted to the required BAPIs or RFCs. Separate connections by environment and by runtime location: the SAP connection is agent-bound; the Salesforce connection is cloud-bound. Do not reuse a personal developer credential in production.
Set connection timeouts, pool sizes, and retry policy on the connection where supported, and keep them consistent across both agents. Log correlation IDs, not payloads containing credentials or personal data. Rotate the service-account secrets before go-live and after any staff change, and document which agent group each connection requires so a future promotion does not silently route SAP traffic through the cloud server.