How does ml-connector handle the on-premises RFC connectivity to SAP ECC?

ml-connector accepts the on-premises SAP NetWeaver Agent URL, username, and password (via SAP NCo or JCo), and calls RFC_READ_TABLE and BAPI functions directly from that agent. The agent must be running on the customer's network with SAP credentials that have read-execute permission on the required BAPIs and tables. ml-connector caches the RFC connection and reuses it across multiple PO and shipment reads to minimize network overhead.

What happens if FedEx rate limits are exceeded or OAuth tokens expire?

ml-connector caches FedEx OAuth 2.0 bearer tokens for the full 1-hour TTL to avoid triggering the 3 tokens-per-second IP limit. If a token expires mid-flight, a 401 response prompts an immediate refresh and automatic retry. If the 1,400 transactions-per-10-seconds quota is hit, ml-connector backs off exponentially and retries; this is rare for typical ECC shipment volumes but is monitored and alerted.

How are tracking numbers and proof of delivery kept in sync between SAP and FedEx?

ml-connector stores the FedEx transactionId as the idempotency key when a label is first created, and retrieves it on each Track API poll to fetch the latest status without creating duplicate shipments. Status events (in-transit, delivered, delivery failure) are polled every few minutes and posted back to SAP via BAPI_PO_CHANGE, so the SAP PO always reflects the live tracking state. If Advanced Integrated Visibility webhooks are enabled, tracking is pushed to ml-connector, reducing polling overhead.

SAP ECCFedEx

SAP ECC and FedEx integration

SAP ECC runs your purchasing and inventory. FedEx moves your packages. Connecting the two automates the freight workflow: purchase orders become shipments, shipments become FedEx labels with tracking numbers, and incoming tracking events update SAP with delivery status and proof of delivery. ml-connector bridges the very different transports - SAP's RFC/BAPI through an on-premises agent and FedEx's REST API - and handles the rate limiting, auth refresh, and idempotency on both sides so you ship faster and lose fewer tracking numbers to manual entry.

How SAP ECC works

SAP ECC exposes vendors, purchase orders, materials, and shipment data through RFC function modules and BAPI APIs, either via an on-premises Netweaver Agent using SAP NCo or JCo, or through OData v2 REST services published on SAP Gateway at a customer-specific hostname and port. BAPI reads require no special setup; writes require RFC credentials and an explicit BAPI_TRANSACTION_COMMIT call to persist changes. OData services must be activated by SAP Basis on a per-service basis via TCODE SICF. SAP ECC has no native webhook registry, so shipment and purchase order data is read by polling RFC_READ_TABLE on demand or on schedule, or via customer-configured IDoc push over HTTP to a registered listener.

How FedEx works

FedEx exposes shipment creation, rate quoting, address validation, tracking, and freight management through REST endpoints at https://apis.fedex.com and https://apis-sandbox.fedex.com. All calls require OAuth 2.0 Client Credentials with API Key and Secret from the FedEx Developer Portal, returning bearer tokens with 1-hour TTL. FedEx enforces IP-level rate limits of 3 tokens per second and 1,400 transactions per 10 seconds per project. Tracking events can be pushed via Advanced Integrated Visibility webhooks (paid subscription) or pulled on demand via the Track API without webhook setup. No SOAP; REST is mandatory.

What moves between them

The main flow runs from SAP ECC into FedEx. Purchase order line items tagged for shipment trigger FedEx label creation calls, passing the material description, weight, quantity, and vendor address from SAP. FedEx returns tracking numbers and label URLs, which are stored back in SAP via BAPI_PO_CHANGE or custom IDoc fields. Tracking events flow back into SAP either via webhook notification (if Advanced Integrated Visibility is enabled) or by polling the Track API on a scheduled interval. Rate quotes from FedEx can also be queried against purchase orders to validate cost before shipment, and shipment cost data is reconciled in SAP as a vendor invoice or freight charge journal.

How ml-connector handles it

ml-connector accepts an on-premises SAP RFC connection string and credentials (NCo or JCo agent URL, username, password) and calls RFC_READ_TABLE to poll purchase orders and shipment records on a schedule. For each shipment, it constructs a FedEx Ship API payload with the recipient address from the PO vendor master, the package weight and dimensions from SAP material master data, and the PO number as the shipment reference. Before each FedEx call, it refreshes the OAuth 2.0 bearer token and caches it for the full 1-hour lifetime to stay under the 3 tokens-per-second IP limit. FedEx returns a transactionId, which ml-connector stores in SAP as the idempotency anchor - on retry, the same transactionId is submitted, and FedEx returns the same tracking number without creating a duplicate label. Tracking events are polled via Track API every few minutes (configurable per customer) and correlated back to the SAP PO by matching the shipment reference. If an on-premises RFC agent is unavailable, ml-connector alerts immediately rather than queuing retries, since agent downtime is a network or SAP Basis issue, not a transient call failure.

A real-world example

A mid-sized discrete manufacturer with SAP ECC on-premises manages vendor shipments for component procurement. Before the integration, the procurement team received POs in SAP, emailed shipment details to FedEx, received tracking numbers by email or phone, and manually entered them into SAP and an Excel tracking log. Month-end reconciliation meant comparing the SAP PO ledger against FedEx billing invoices by hand, and lost tracking numbers meant days of calls to vendors and carriers to recover proof of delivery. With SAP ECC and FedEx connected, each approved PO triggers an automatic FedEx shipment request with the correct weight, address, and reference, and tracking numbers are available in SAP within minutes. Finance can see freight costs tied to each PO, and logistics has a single source of truth for in-transit status without re-keying.

What you can do

Create FedEx shipments and labels from SAP purchase orders, passing vendor addresses, materials, weights, and quantities to FedEx without manual re-entry.
Query FedEx rate quotes against SAP purchase orders to validate freight costs before committing to shipment.
Retrieve FedEx tracking numbers and store them back in SAP via BAPI so the PO reflects delivery status end-to-end.
Poll FedEx tracking events and sync them into SAP shipment records on a schedule you control, with full audit trail of each status change.
Authenticate SAP ECC via RFC/BAPI using an on-premises agent, and FedEx via OAuth 2.0 with token caching to respect IP rate limits.

Questions

How does ml-connector handle the on-premises RFC connectivity to SAP ECC?: ml-connector accepts the on-premises SAP NetWeaver Agent URL, username, and password (via SAP NCo or JCo), and calls RFC_READ_TABLE and BAPI functions directly from that agent. The agent must be running on the customer's network with SAP credentials that have read-execute permission on the required BAPIs and tables. ml-connector caches the RFC connection and reuses it across multiple PO and shipment reads to minimize network overhead.
What happens if FedEx rate limits are exceeded or OAuth tokens expire?: ml-connector caches FedEx OAuth 2.0 bearer tokens for the full 1-hour TTL to avoid triggering the 3 tokens-per-second IP limit. If a token expires mid-flight, a 401 response prompts an immediate refresh and automatic retry. If the 1,400 transactions-per-10-seconds quota is hit, ml-connector backs off exponentially and retries; this is rare for typical ECC shipment volumes but is monitored and alerted.
How are tracking numbers and proof of delivery kept in sync between SAP and FedEx?: ml-connector stores the FedEx transactionId as the idempotency key when a label is first created, and retrieves it on each Track API poll to fetch the latest status without creating duplicate shipments. Status events (in-transit, delivered, delivery failure) are polled every few minutes and posted back to SAP via BAPI_PO_CHANGE, so the SAP PO always reflects the live tracking state. If Advanced Integrated Visibility webhooks are enabled, tracking is pushed to ml-connector, reducing polling overhead.

Connect SAP ECC and FedEx

Free to use. Add your credentials, ping your real systems, and see if we fit.

Get started