Skip to content
Santiago Lopez de Haro
All projects
BlueBoot
Projects as employee

Enterprise Procurement & Supplier Collaboration Portal

A dual-facing buyer and supplier portal on SAP BTP that runs the full purchase-order lifecycle, from internal approvals to supplier negotiation, before syncing agreed changes back to SAP S/4HANA.

Enterprise Procurement & Supplier Collaboration Portal

Highlights

Buyer and supplier portals on SAP Build Work Zone, backed by a CAP service on SAP BTP
Sequential PO approvals in SAP Build Process Automation, orchestrated level by level from CAP
Two-way S/4HANA integration: PO output inbound, approvals and agreed changes back through the Cloud Connector
Replay-safe workflow callbacks with post-commit notifications and bounded timeouts
Okta to SAP Cloud Identity Services provisioning through a SCIM proxy
Email log with admin resend, so no notification is silently lost

The Challenge

Penguin Solutions required a bridge between their internal SAP S/4HANA environment and their external supplier network. The goal was to eliminate manual communication gaps, reduce errors in Purchase Order (PO) processing, and provide a secure, real-time negotiation layer for schedule and price changes that traditional ERP interfaces often lack for external users.

The Solution

We developed a dual-facing web portal that acts as an intelligent orchestration layer. By integrating a cloud-based backend with the core ERP, we created a system that manages the entire PO lifecycle—from initial internal approval to final supplier commitment. The solution ensures that no data is written to the core SAP system until it has been fully vetted and agreed upon by all stakeholders.

Core Features

  • Automated Approval Workflow: Integrates an automated sequence (SBPA) where internal stakeholders approve or reject POs based on importance. This ensures that suppliers only see high-quality, pre-approved documents.
  • Bi-Directional Negotiation: Suppliers can 'Commit as is' or 'Request Changes' (schedules or pricing). This initiates a digital negotiation loop where buyers can accept, reject, or provide remarks, maintaining a full audit trail of the conversation.
  • Live Data Enrichment: The portal dynamically combines live ERP data with portal-specific metadata (status history and remarks), providing a comprehensive view without duplicating the entire database.
  • Intelligent Notifications: An automated email engine ensures that buyers and suppliers are alerted the moment a pending action—such as a new PO, a rejection, or a change request—requires their attention.
  • Secure Identity Management: Utilizes advanced JWT-based access control to ensure suppliers only see data relevant to their specific IDs and Purchase Groups.

How it Works

When a PO is created in SAP S/4HANA, it is intercepted and sent to our cloud layer. It enters a 'Pending for Approval' (PFA) state, moving through a sequential chain of internal approvers. Once cleared, the PO is published to the Supplier Portal.

Suppliers then interact with the PO in real-time. If changes are requested, the Buyer Portal allows internal teams to review, comment on, and ultimately approve modifications. Once a final agreement is reached, the system automatically synchronizes the updated data back to the SAP ERP via OData services, ensuring the 'Single Source of Truth' is maintained without manual entry.

Technical architecture on SAP BTP

The portal runs in one SAP BTP subaccount on Cloud Foundry. A Node.js service built with the SAP Cloud Application Programming Model (CAP) owns the collaboration logic and persists to PostgreSQL on SAP BTP. The buyer, supplier and administration UIs are SAPUI5 apps served from the HTML5 Application Repository through SAP Build Work Zone, and supplier attachments are stored in SAP Document Management Service.

SAP BTP L2 solution diagram: Build Work Zone and SAPUI5 apps, the CAP service on Cloud Foundry with PostgreSQL, Build Process Automation, platform services, Cloud Identity Services with Okta provisioning, and SAP S/4HANA behind the Cloud Connector.
L2 solution diagram, following the SAP BTP solution diagram guideline (Horizon). Click to open at full resolution.

Integration with SAP S/4HANA

  • Inbound: purchase-order output in S/4HANA pushes every new, changed or closed PO to a dedicated ERP-to-CAP service, authenticated as a technical OAuth client.
  • Outbound: approval results and agreed changes go back through the Destination and Connectivity services and the Cloud Connector, with principal propagation for user-initiated calls.
  • Live reads: goods receipts, consignment stock and PO PDFs are read from S/4HANA on demand instead of being copied into the portal.

Approval orchestration

CAP owns the approval chain and SAP Build Process Automation owns each approver's task. For every level, CAP starts a workflow for that approver. The decision calls back into CAP with the approver's own token through an OAuth2 user-token-exchange destination, so every approval is attributable to a person. CAP records each level on the PO in S/4HANA, skips consecutive levels held by the same approver, and publishes the PO to the supplier once the chain is complete.

BPMN 2.0 collaboration across SAP S/4HANA, SAP BTP (CAP service, approver, buyer lanes) and the supplier: approval loop, publication, supplier commitment or change request, buyer review and write-back.
Solution Process Flow (BPMN 2.0 collaboration): approval loop, supplier negotiation and write-back.

Designing for the workflow engine's limits

Build Process Automation aborts a service call after 240 seconds and leaves the step waiting for a manual retry, so the callbacks are designed around that budget:

  • Nothing slow runs inside the request: notifications go out after the database commit, each one isolated so a failing mail server cannot suppress the others.
  • Every call to S/4HANA, the mail server and the workflow API carries an explicit timeout, within a shared time budget per request.
  • A retried approval is recognised and returns the original result instead of applying the decision twice.

Identity and access

Employees are provisioned from Okta into SAP Cloud Identity Services through a small SCIM proxy that normalises their attributes, while suppliers are managed in Cloud Identity Services with their vendor IDs as a user attribute. Identity groups map to role collections, and every service operation declares the roles it requires, which an automated authorization test enforces on every build.

Data ownership

SAP Solution Data Flow: S/4HANA is the system of record for purchase orders, suppliers and goods movements; the portal owns approval levels, change requests, attachment references, PO history and the email log.
Solution Data Flow: which component is the system of record for each data object, and what moves where.

S/4HANA stays the system of record for purchase orders, suppliers and goods movements. The portal owns only what S/4HANA has no place for: approval levels, change requests, attachment references, the PO change history and an email log that records every notification, including the ones that could not be sent, so administrators can resend them.

Cloud-native, and shaped for its workload

The portal does very little computation. A typical request reads from PostgreSQL, calls S/4HANA through the Cloud Connector, sends mail through the SMTP relay or hands a file to SAP Document Management Service, and spends most of its time waiting on the network. The stack was chosen for that I/O-bound profile.

  • Node.js, because the backend is glue: the BTP backend's job is to tie the solution together over the network: S/4HANA, the SMTP relay, Document Management Service and SAP Build Process Automation (SBPA), where approvers approve or reject POs and whose decisions call back into the service. Nearly every request is a chain of remote calls with very little computation in between, which is the workload Node.js handles best. A single small instance serves both portals and the workflow callbacks, and CAP and the SAP Cloud SDK give it first-class access to the BTP services it depends on.
  • Slow work off the request path: notifications and PO PDF fetches run as background jobs after the transaction commits, so nobody waits on the mail server.
  • Files bypass the backend: both portals upload attachments straight to Document Management Service through the application router. CAP stores only the reference and who can see it.
  • Managed PostgreSQL: PostgreSQL on SAP BTP, provisioned from the deployment descriptor. Production runs across availability zones with storage autoscaling, encryption at rest and automated backups, and each release migrates the schema in a one-off Cloud Foundry task. Because S/4HANA keeps the bulk of the data, the database holds only the portal's overlay and most queries are lookups by PO number.
  • Cloud-managed secret service: endpoints and credentials for S/4HANA, the mail server, SBPA and Document Management Service live in the BTP Destination service and are resolved at runtime, so no secret is stored in code and rotating one is a change in the BTP cockpit, not a redeploy.

Each component matches the job it does: a lightweight, non-blocking service gluing S/4HANA, SMTP and BTP services together, on top of managed infrastructure that the team does not have to operate.

Gallery