Diagnosing BTP MTA Subscription Failures: A Log Analysis Playbook

Dr. Sarah Chen breaks down what you need to know

If you have deployed a well-tested Multi-Target Application (MTA) to a new subaccount and still hit a generic subscription error, you know BTP’s multi-tenancy layer does not hand you a single root cause. The error usually lives across three places: the application runtime, the service broker, and the subaccount configuration. After 16 years of chasing these failures, I can tell you the fastest path to resolution is disciplined log correlation, not guesswork.

The Real Story

Subscription failures in BTP MTAs rarely point to a bad line of application code. In most cases I have analyzed, the problem is a mismatch between what the deployed MTA expects and what the target subaccount actually provides. The provider subaccount may work fine, but the new consumer subaccount differs in an entitlement, a route domain, a subdomain pattern, or a missing service instance.

The BTP cockpit does offer application logs, but they are often too coarse for subscription events. I always start with the CF CLI because it lets me capture runtime logs during the subscription attempt. For example:

cf login -a <region>.hana.ondemand.com -o <org> -s <space>
cf apps
cf logs <app-name> --recent | grep -iE "subscription|tenant|callback|error"

If --recent does not show enough, open a second terminal and run:

cf logs <app-name> > /tmp/subscription-trace.log

Then trigger the subscription again from the cockpit or the SaaS Manager API. The live stream captures the actual callback requests and routing errors. I have seen teams spend days on a failure that was visible in five seconds of live log output.

What This Means for You

For developers, the key shift is to stop treating subscription errors as a single event. Break the flow into three checks:

• Application runtime logs show whether multitenancy callbacks execute and whether tenant host patterns match.
• Service instance status shows whether the required backing services were provisioned in the consumer subaccount. Use cf service-instances and cf service <name> to verify creation state.
• Subaccount configuration is where silent mismatches hide. A working provider subaccount and a new consumer subaccount can differ in subdomain, entitlements, quota, or trust settings in ways the MTA cannot self-correct.

For consultants and architects, the same three checks apply but at a governance level. Before repeating any deployment, compare the two subaccounts systematically. Something as simple as a missing service plan entitlement will produce a subscription error that no amount of application debugging will fix.

Here is a quick comparison sequence:

# capture the working environment baseline
cf target -o <working-org> -s <working-space>
cf service-instances > /tmp/working-services.txt
cf env <working-app> > /tmp/working-env.txt

# now capture the failing environment
cf target -o <new-org> -s <new-space>
cf service-instances > /tmp/new-services.txt
cf env <new-app> > /tmp/new-env.txt

diff those files. Look for missing services, wrong plans, and divergent environment variables. I have watched this single comparison resolve more “unexplainable” subscription errors than any other step.

Action Items

• Capture both cockpit logs and CF CLI live logs during a subscription attempt. Do not rely on --recent alone if the failure happened minutes ago.
• Compare the working and failing subaccount configurations at the summary level: entitlements, subdomain, route domains, service plans, and route mappings.
• Review MTA deployment logs and service instance creation status for the target subaccount. A deployment that reports success may still leave a service instance in an inconsistent state.
• Validate multitenancy callbacks and route configurations. In your mta.yaml, confirm the tenant host pattern matches the actual tenant subdomain:

modules:
  - name: approuter
    properties:
      TENANT_HOST_PATTERN

## References

- BTP subscribe app error . How to check log to find reason- [SAP AI Core Documentation](https://help.sap.com/docs/SAP_AI_CORE)
- SAP Community Hub

---

## References

- [SAP AI Core Documentation](https://help.sap.com/docs/SAP_AI_CORE)
- [BTP subscribe app error . How to check log to find reason](https://community.sap.com/t5/technology-q-a/btp-subscribe-app-error-how-to-check-log-to-find-reason/qaq-p/12393930)
- [SAP Community Hub](https://community.sap.com/)