Manufacturer Analytics Portal
Architected a centralized secure entry point for external manufacturers, replacing legacy Power BI portals with a unified SAP BTP ecosystem.
For Decision-Makers
Executive Summary
An enterprise modernization that consolidated fragmented partner reporting into a unified SAP BTP portal. Replaced 40+ legacy entry points with a single Build Work Zone experience secured by federated identity, CAP-based attribute access control, and 22 custom Fiori applications—delivering a single secure entry point for the external partner community.
Business Challenge
What was at stake
An external partner network accessed performance and reporting data through a patchwork of legacy portals and analytics tools. Each surface had distinct login flows, partial data coverage, and inconsistent security boundaries—creating audit risk and slowing every partner onboarding.
Key Problems
- Fragmented entry points spanning 40+ legacy portals
- Partial or duplicated data per portal with no canonical view
- Identity sprawl across partner organizations and internal directories
- Weak tenant isolation enforced inconsistently across surfaces
- High onboarding cost and friction per partner organization
Stakeholders Affected
External manufacturer and partner network, internal IT operations, data governance, and security/compliance reviewers.
Advanced Identity Federation
Implemented a seamless SSO experience by federating Okta with SAP Cloud Identity Services (IAS).
Mapped custom Okta attributes (Manufacturer_ID, Region_Code) to SAML assertions.
Configured SAP IAS as the proxy to pass these attributes into the BTP XSUAA service.
Implemented Attribute-Based Access Control (ABAC) in the CAP layer to restrict data visibility based on these passed attributes.
Technical Approach
Multi-tenant BTP architecture led from identity outward
Began with identity boundaries and data isolation before any UI work. Built SAP Build Work Zone as the partner-facing shell and standardized data exposure through a CAP service layer that enforces attribute-based access control at the data tier—not the UI.
Established the partner attribute model (manufacturer ID, region) sourced from the external IdP
Deployed SAP Cloud Identity Services (IAS) as the identity proxy translating SAML attributes into XSUAA principals
Built a Node.js CAP service layer enforcing ABAC at the data boundary
Consolidated analytics into 22 SAPUI5 applications launched from Build Work Zone
Established CI/CD for zero-downtime updates across the partner community
The Process
Project Lifecycle
Analyzed existing Power BI workflows and mapped data requirements for external manufacturer personas. Identified security gaps in cross-platform authentication.
Designed a robust architecture using SAP BTP Cloud Foundry. Implemented SAP Build Work Zone and custom SAPUI5 applications for the frontend and SAP CAP (Node.js) for the service layer.
Led a team to develop 15 custom SAPUI5/Fiori applications. Integrated SAP Datasphere for real-time analytics and implemented Okta for secure external identity management.
Managed a phased rollout strategy reaching go-live in December 2025. Established CI/CD pipelines to ensure zero-downtime updates for the manufacturer community.
Technical Deep Dive
Project Details
Built on SAP BTP, this architecture enables secure, multi-tenant access...
// CAP CDS Service for Manufacturer Analytics
service ManufacturerService @(path: '/api/v1/analytics') {
@readonly
entity SalesPerformance as select from db.Sales {
key ID,
manufacturerName,
productCategory,
monthlyRevenue,
growthPercentage,
virtual marginIndicator : String
};
annotate SalesPerformance with @(
requires: 'authenticated-user',
restrict: [{ grant: 'READ', where: 'manufacturerId = $user.id' }]
);
}Architectural Decisions
Choices that shaped the build
Build Work Zone as the portal shell
Decision
Use SAP Build Work Zone as the unified partner entry rather than a custom portal framework.
Rationale
Native BTP integration, app catalog, branding, and Fiori Launchpad standards reduce custom code and stay aligned with SAP's roadmap.
CAP service layer for all data access
Decision
Centralize data exposure through CAP services rather than direct UI-to-backend queries.
Rationale
Single point to enforce ABAC, version APIs, and isolate UIs from backend volatility as systems evolve.
Identity federation with IAS as proxy
Decision
Federate the external IdP (Okta) through SAP IAS rather than registering partner users in SAP IDM.
Rationale
User lifecycle stays with the partner organization. SAP-side identity remains lightweight, auditable, and decoupled from corporate IdP churn.
ABAC enforced in the data layer
Decision
Enforce tenant boundaries via CAP attribute restrictions rather than UI-level filtering.
Rationale
UI can never be trusted as a security boundary. ABAC at the data layer ensures partner A cannot read partner B regardless of frontend defects.
Phased rollout by partner cohort
Decision
Onboard partners in waves rather than a single big-bang cutover.
Rationale
Identity flows and partner-specific data quirks surface incrementally, and rollback per cohort remains feasible.
Key Tradeoffs
What was chosen, and against what
Portal shell
Chose
SAP Build Work Zone
Instead of
Custom Next.js/React portal
Reasoning
Time-to-value, native Fiori catalog, and SAP roadmap alignment outweighed custom flexibility. A custom shell would have meant rebuilding navigation, branding, and identity glue from scratch.
Data access layer
Chose
CAP service layer
Instead of
Direct OData from existing systems to the UI
Reasoning
Centralized ABAC, API versioning, and stable contracts justified the extra layer to operate. Direct OData would have leaked backend changes into every app.
Authorization model
Chose
Attribute-based access control (ABAC)
Instead of
Role-only RBAC
Reasoning
Partner counts grow into the hundreds. One role per partner is unmaintainable; ABAC scales as data, not configuration.
Identity federation topology
Chose
IAS as a federation proxy
Instead of
Direct SAML from corporate IdP to XSUAA
Reasoning
IAS supports attribute mapping, conditional access, and decouples corporate identity changes from BTP. Direct SAML couples both ends too tightly.
Measurable Outcomes
Results
Key Impact
22 Custom Apps Deployed
22
Applications Built
+40%
User Adoption
40
Legacy Portals Retired
Qualitative Outcomes
Beyond the numbers
- Single secure entry point established for the external partner community
- Consistent partner experience across analytical workflows
- Faster partner onboarding—federation eliminates SAP-side user provisioning
- Audit-ready security model with isolation enforced at the data tier
- Foundation in place for adding new analytics apps without re-architecting identity
Beyond the 22 deployed applications and 40 retired portals, the program produced a reusable security and delivery template for future external-facing BTP work.
Lessons Learned
What generalizes
- 01
Identity attributes must be agreed across partner IdP, IAS, and CAP before app development—late discovery cascades into UI rework.
- 02
ABAC is only as strong as the negative-test program. Explicit "partner A cannot read partner B" tests are non-negotiable.
- 03
Build Work Zone information architecture matters more than visual polish. External users abandon a portal when they cannot find their app on day one.
- 04
Phased onboarding requires coordinated communications. Technical readiness alone does not drive adoption.
- 05
CAP ABAC requires care around joins and projections. Treating ABAC as automatic leads to silent leaks under load.
When This Approach Makes Sense
Is this a fit for your program?
Strong fit when
- External users—partners, distributors, manufacturers, dealers—need secure portal access to SAP data
- Identity federation with corporate or partner IdPs is required
- Multi-tenant isolation is a hard, audited requirement
- A roadmap exists to consolidate legacy partner portals
- Stakeholders are committed to SAP-aligned architecture
Probably not when
- The audience is internal employees only and Fiori Launchpad already meets the need
- SAP BTP is not part of the strategic roadmap
- The use case is content-heavy public marketing rather than authenticated data access
Next Step
Planning an SAP BTP portal for external users?
If your program involves federation, multi-tenant isolation, or consolidating legacy partner entry points, share a short brief and I'll respond with how a similar engagement would be structured.
Not sure how to engage? See engagement options.
Related Services
See engagement options or contact Bryan to discuss a similar engagement.