1. Get and verify the compatible package
The BTP add-on is version 0.1.0 and pairs with the separately licensed base source version 1.1.1. It retains discovery, metadata inspection, bounded previews, sales-item reads, filters, paging, search, charts, CSV export and public offline help.
Download the signed source and release metadata from your library. Confirm the Store public key fingerprint through a separately trusted ProgreTech channel, then verify the signature and archive hash before extraction. The package includes native CodeSeal manifest PTCS-C65AB4F394C3C148 for its protected source selection.
Open your purchased-source library
2. Select your BTP services
The default profile requires Cloud Foundry runtime quota, xsuaa/application, identity-provider trust and a buyer-managed role collection. Durable configuration uses your named user-provided service buyer-intake-config.
For selected service bindings, use destination/lite and your approved backend read grants. Cloud Connector HTTP access also requires connectivity/lite, a tunnel, virtual HTTP system and resource allowlist. Confirm plans, region availability, quota and costs in your own subaccount before creating services.
3. Prepare your tools and buyer packet
Install btp CLI, CF CLI v8, the SAP MultiApps plugin and the MTA Build Tool through your approved routes. The CF profile uses its Python 3.13 lock, Node 22 and GNU Make. Keep these separate from the base Linux profile and its Python 3.14 lock.
Open docs/en/buyer-index.html in the downloaded source. It links the Windows, Ubuntu and macOS BYOM setup, implementation prompts and buyer-owned Hetzner, AWS, Azure and Google Cloud procedures. The full BTP cookbook is btp/docs/en.md.
btp --version
cf version
cf plugins
mbt -v4. Keep configuration private and stage the source
Copy btp/config.example.json and btp/buyer.mtaext to private paths outside the source. Set the exact HTTPS public origin, approved router route, redirect URI and unique xsappname. Save at least 48 random characters directly into config.session_secret using your secret manager, and keep an encrypted binding backup.
Stage into a new directory. On Windows use py -3.13 in place of python3. For named connectors, add --connectors and follow the cookbook’s matching service-name and binding_names changes; use connectivity only for the selected Cloud Connector route.
python3 btp/build.py --output /private/new-intake-stage5. Choose the deployment archive
The package includes mta_archives/pt-data-intake-btp_0.1.0.mtar for the default profile and mta_archives/pt-data-intake-btp-connectors_0.1.0.mtar for the connector variant. The connector variant uses existing Destination and Connectivity instances with connectors.mtaext; the cookbook explains the Internet-only adjustment.
Use your administrator’s approved org, space, routes and entitlements. Keep the core on its internal route and apply the router-to-core TCP 8080 network policy. Follow the shipped cookbook for MTA deployment or the alternative manifest.yml direct-push layout, with one installation owner and matching private extensions.
6. Assign the reader role and check consent
Assign the XSUAA IntakeReader role template through your buyer role collection. Sign in through the approuter, choose a language and grant session read consent. This CF copy uses SSO; the independently configured base installation retains its private operator login.
Start with the included synthetic discovery and a 24-row preview, then one explicitly authorized backend read. Check role and token denials, CSRF, logout, field mappings, paging, CSV formula protection and private-cache boundaries. Recheck identity and consent when the user changes.
7. Keep a recovery path and use the implementation prompts
Keep the previous reviewed MTAR, matching extensions and encrypted configuration backup. In your approved maintenance window, restore buyer-intake-config, rotate the session secret and restage the core. Roll back with the retained archive and matching bindings, then repeat the identity, consent and bounded-read checks. CF instance disk holds an ephemeral configuration copy; your protected service backup is the recovery source.
Use the full cookbook’s BYOM implementation prompt with your approved AI CLI to prepare a reviewable change. It keeps credentials and business rows out of prompts, preserves the base workflows and requires your target approval before service creation or deployment. Your technical team can also follow the same manual implementation guidance.
Base backup and recovery walkthrough