Hey everyone, new to ServiceNow and GRC here. We're trying to use the automated testing features for compliance checks against our SAP environment.
I followed the docs to set up the MID Server and connect to our SAP system, but the tests always fail with generic connection errors. The logs aren't super helpful. Has anyone actually gotten this to work?
Our setup is pretty standard SAP on AWS. In Terraform, we provisioned the EC2 instance for the MID Server like this:
```hcl
resource "aws_instance" "snow_mid_server" {
ami = "ami-12345"
instance_type = "t3.medium"
subnet_id = aws_subnet.private.id
vpc_security_group_ids = [aws_security_group.mid_server.id]
}
```
Do I need specific ports open other than what the ServiceNow docs say? Or is there a known quirk with SAP roles/permissions? Any pointers would be a lifesaver. Feeling a bit stuck 😅
Connection errors are usually network, not SAP quirks. Your Terraform shows a private subnet - can the MID Server actually route to your SAP host? Check VPC routes and security groups.
ServiceNow docs are notoriously vague on ports. SAP uses a ton. You'll likely need 33xx for the gateway and possibly 5xx00 for the message server, depending on your stack.
Skip the automated testing for now. Go to the MID Server's ECC agent probe and run a simple connectivity test manually. That'll tell you if it's even talking. If that fails, no automated test will work.
Generic logs are useless. Enable debug logging on the MID Server's SAP probes. The logs are in /logs on the MID Server instance, not in ServiceNow. Look for Java exceptions.
Simplicity is the ultimate sophistication
Based on the Terraform snippet you provided, the subnet placement is likely your primary obstacle. A private subnet without a NAT gateway or specific VPC endpoints for ServiceNow's control plane will prevent the MID Server from phoning home, which is a prerequisite for any SAP connectivity. The automated tests won't even attempt to reach SAP if the MID Server can't establish its management channel.
Beyond that, the SAP connection itself requires a technical user with explicit authorizations, not just standard dialog roles. The SAP_GRAC_SERVICENOW role provided by SAP is a necessary starting point, but you often need to supplement it with additional object-level permissions for the specific tables and transactions your tests target. The generic errors from ServiceNow usually mask an authorization failure at the SAP layer.
I would prioritize verifying MID Server health in the ServiceNow instance first, then move to the ECC probe as user188 suggested. Only after a basic RFC connection is proven should you attempt to debug the automated testing framework.