Using Multiple-Origin Composition in SAP OData Provisioning for BAS Development

Introduction

While migrating SAP Fiori applications from SAP Web IDE to SAP Business Application Studio, we investigated Multiple-Origin Composition (MOC) in SAP OData Provisioning as an alternative way of accessing backend data during local development.

MOC is designed for an OData service that is assigned to multiple backend destinations. Instead of accessing only the default backend, OData Provisioning can retrieve data from multiple origins and compose the successful results into one service response. MOC also supports OData $batch requests. Multi Origin Composition [https://he…6bfca.html]

In our scenario, the default backend destination used Principal Propagation and had to remain the default because productive SAP Build Work Zone users depended on it. During our initial BAS testing, the required business-user context was not available through the authentication method being tested, while a second destination using technical authentication could successfully access the same backend service.

Changing the ODP default destination was not acceptable because it would also affect productive users. Creating another Integration Suite landscape purely for development was also unnecessary. MOC therefore provided a useful temporary option for local BAS development.

It worked particularly well for collection-oriented scenarios such as tables, searches and value helps. However, it also exposed an important limitation: MOC makes the OData service origin-aware. Existing applications that assume a normal single-origin entity key may therefore require application changes for single-entity navigation and update scenarios.

What Multiple-Origin Composition Does

Normally, a registered OData service called without MOC uses its configured default destination.

With MOC, OData Provisioning can access multiple destinations assigned to the service and compose their results.

SAP documents the MOC read URL using the service version followed by ;mo: Multi Origin Composition [https://he…6bfca.html]

/odata/<namespace>/<service>;<version>;mo/<EntitySet>

For $batch, the corresponding URL is:

/odata/<namespace>/<service>;<version>;mo/$batch

If ;mo is omitted, OData Provisioning uses only the default system. Multi Origin Composition [https://he…6bfca.html]

MOC is therefore more than simple URL routing. It changes how OData Provisioning resolves the registered service and how entities from different origins are represented.

Our BAS Development Scenario

Our registered OData service had two backend destinations.

The first destination used Principal Propagation and remained the productive default.

The second destination used technical authentication and could access the same backend service without depending on the interactive business-user context.

During our initial BAS testing, the default Principal Propagation destination could not complete the request successfully, while the technical origin could.

We wanted to preserve the productive ODP configuration, so instead of changing the default destination, we used MOC only during local BAS development.

Using MOC Only During Local BAS Development

We did not put ;mo into the productive manifest.json.

Instead, we used a separate ui5-local.yaml and the SAP Fiori Tools fiori-tools-proxy middleware to rewrite the service path during local preview.

The application continued using its normal /backend OData URL.

For metadata, we kept the regular ODP service URL. For collection and $batch traffic, the local proxy changed the service root to its MOC form.

For example, a local request to:

/backend/odata/sap/Z_SAMPLE_SERVICE_SRV/

was routed to:

/odata/sap/Z_SAMPLE_SERVICE_SRV;v=1;mo/

while metadata continued to use:

/odata/sap/Z_SAMPLE_SERVICE_SRV/$metadata

This allowed the SAPUI5 application itself to remain unaware of the local MOC configuration.

The important point was that the change existed only in ui5-local.yaml. The application deployed to SAP Build Work Zone remained on the normal OData contract.

Error Tolerance Was Essential

MOC alone was not sufficient in our scenario.

By default, when one of the destinations participating in MOC returns an error, that failure can cause the composed request to fail.

SAP OData Provisioning provides Error Tolerance for this situation. When Error Tolerance is enabled, an error is returned only when data retrieval from all participating backends fails. If only some origins fail, successfully retrieved data from the remaining origins can still be returned. Multi Origin Composition [https://he…6bfca.html]

In our test, the Principal Propagation origin failed while the technical origin succeeded.

After enabling Error Tolerance, OData Provisioning could return the data from the successful origin rather than failing the entire BAS request.

Without Error Tolerance, MOC did not solve our local scenario because the inaccessible origin could still cause the complete request to fail.

Metadata Caching Was Equally Important

We also found that Error Tolerance alone was not enough.

The stable configuration in our environment required Metadata Cache to be enabled and Destination-Based Metadata Caching to be disabled.

This mattered because one participating destination could not be accessed successfully by the current BAS caller.

Disabling destination-based metadata caching allowed OData Provisioning to work with common cached metadata instead of tying metadata processing to the inaccessible origin.

This configuration should only be used when the participating destinations expose compatible metadata for the registered service.

After changing the cache configuration, we cleared the existing service metadata cache so OData Provisioning could rebuild it using the new settings.

The Combination That Worked

No single setting solved the BAS scenario by itself.

The combination that worked for us was MOC in the local runtime URL, Error Tolerance enabled, Metadata Cache enabled, Destination-Based Metadata Caching disabled, and at least one backend origin capable of returning data successfully.

This allowed BAS to consume real backend data without changing the productive default destination.

Where MOC Worked Well

MOC worked particularly well for collection-oriented operations.

We successfully used it for list and table data, value helps, search results, filtering, collection reads, OData $batch requests and initial application loading.

These scenarios fit MOC naturally because they primarily process feeds or collections that can be composed from several origins.

For a list-oriented application, this can support a significant part of local development.

The Important Limitation: SAP__Origin

The main application-level limitation appeared when we tested single-entity navigation.

Consider a normal OData service where an entity is identified by one business key:

BusinessEntity('1000123')

In a single-origin service, that is sufficient because 1000123 uniquely identifies the entity.

With MOC, the same business key can potentially exist in more than one backend origin.

For example, 1000123 could exist in both ORIGIN_A and ORIGIN_B.

The business key by itself is therefore no longer enough to identify which physical backend record is intended.

The MOC representation introduces origin information, commonly exposed using SAP__Origin, so the entity can remain associated with its actual backend origin.

Conceptually, a normal entity identity such as:

BusinessEntity('1000123')

can become an origin-aware identity similar to:

BusinessEntity(BusinessKey='1000123',SAP__Origin='ORIGIN_A')

The exact business-key property name and the actual value of SAP__Origin must always come from the real MOC service metadata and response. They should not be guessed or hardcoded.

What Happened in Our Custom Application

Our custom SAPUI5 application was originally built for a single-origin OData service.

Some application logic navigated to individual records using the normal service contract. Conceptually, the resulting request looked like:

BusinessEntity('1000123')

Collection requests through MOC worked correctly.

However, when the application tried to address an individual entity using the original single-key representation, OData Provisioning rejected the request because the MOC version of the entity expected origin-aware key information.

In our case, the error indicated that the expected key predicate information was incomplete.

This was not a BAS connectivity failure and it was not an authentication problem.

The application was using the key contract of the original single-origin service against the origin-aware MOC representation.

A useful diagnostic pattern therefore emerged: the list page can work while object-level navigation fails.

When this happens with MOC, entity-key handling should be investigated before assuming that the backend connection is failing.

Why Custom Applications May Need Program Changes

If MOC is going to become part of a custom application’s supported architecture, the application needs to become origin-aware.

An application that previously retained only a business key such as 1000123 may also have to preserve the SAP__Origin value returned with that entity.

When the application subsequently addresses that entity, it needs to use the complete identity expected by the MOC service.

This can affect single-entity reads, object-page navigation, navigation-property requests, $expand, updates, deletes, deep links, actions, function calls and entity operations inside $batch requests.

The application should not simply hardcode something such as SAP__Origin='ORIGIN_A'.

Different records can originate from different backend systems. The origin must therefore come from the actual selected entity returned by the service.

Prefer Metadata-Driven Entity-Key Handling

A custom SAPUI5 application intended to support MOC should avoid manually concatenating OData URLs wherever possible.

A legacy implementation may assume that an entity always has one unnamed string key and construct a path such as:

BusinessEntity('1000123')

A MOC-capable implementation may need enough information to construct an origin-aware entity identity such as:

BusinessEntity(BusinessKey='1000123',SAP__Origin='ORIGIN_A')

The exact canonical format must be determined from the actual MOC metadata.

The required application change is therefore not simply “append SAP__Origin to every URL.”

Instead, the application must treat the entity as an origin-aware OData entity and retain the complete identity returned by the service.

Navigation Properties Are Affected Too

The impact is not limited to direct single-entity reads.

An existing application might navigate using:

BusinessEntity('1000123')/ToAttachments

or:

BusinessEntity('1000123')?$expand=ToAttachments

If MOC changes the parent entity into an origin-aware identity, the parent must first be identified correctly before OData Provisioning can resolve the related entities.

Conceptually, the MOC-aware request may therefore need the origin as part of the parent key before navigating to ToAttachments.

This is why simply adding ;mo to the service URL can be enough for the initial table to load while object-page navigation still fails later.

$batch Requires Additional Attention

MOC officially supports $batch. SAP documents the MOC batch URL as /odata/<namespace>/<service>;<version>;mo/$batch. Multi Origin Composition [https://he…6bfca.html]

However, the outer $batch URL is only part of the request.

The multipart $batch body contains individual OData requests.

If one of those embedded requests addresses a specific entity, that embedded request must also use the correct origin-aware entity identity.

An operation that previously addressed BusinessEntity('1000123') may therefore also need the appropriate SAP__Origin when executed inside the MOC batch.

This is why we decided against using a simple regular-expression middleware to rewrite entity URLs locally.

An OData $batch payload can contain multipart boundaries, embedded HTTP requests, change sets and multiple entity references. Making an application properly MOC-aware requires understanding the OData entity model rather than blindly changing URL text.

Why Applications Designed for Multiple Backends Are Better Candidates

MOC is a natural fit for applications that are intentionally designed to consume records from several backend origins.

SAP My Inbox is a useful example of the type of standard multi-backend application where backend origin is already an important part of the scenario.

For an origin-aware application, origin information is not an unexpected additional property introduced during development. The application already understands that records can belong to different source systems.

A custom application originally designed around one backend may contain single-origin assumptions that become visible only after MOC is enabled.

This does not mean custom applications cannot support MOC. It means the application and the OData contract must both be designed for the multi-origin model.

Error Tolerance Should Be Used Carefully

Error Tolerance was extremely useful during our BAS testing because one origin was unavailable to the local caller while another origin remained usable.

However, Error Tolerance should not automatically become a productive security or routing strategy.

SAP guidance has cautioned against using fault tolerance as a replacement for appropriate backend routing where users are intended to access only specific backend systems. Support of multiple backend systems – How to use Multi Origin Composition and Routing [https://co…p/13280485]

For development and troubleshooting, Error Tolerance can be very useful. For productive architecture, the reason an origin is failing should still be understood.

Monitoring and Troubleshooting in OData Provisioning

Monitoring was another area where our expectations had to be adjusted.

In our OData Provisioning environment, the monitoring entries were relatively lightweight. They provided information such as the timestamp, service information, error description and transaction information.

However, the monitor did not behave like a deeply linked end-to-end tracing tool where every error message could be clicked to navigate through all downstream processing details.

In practice, detailed troubleshooting still required correlation with the SAP backend.

For failures reaching SAP Gateway, we used /IWFND/ERROR_LOG and /IWBEP/ERROR_LOG to inspect the backend error.

The timestamp and transaction information from OData Provisioning were useful for correlating the ODP failure with the backend log entry.

This is worth understanding before troubleshooting a complex MOC scenario. ODP monitoring can identify that composition or backend processing failed, but backend-specific diagnosis may still need to be completed in SAP Gateway.

Practical Troubleshooting Approach

When a MOC request fails, first verify that the runtime URL actually contains ;<version>;mo.

Then determine whether every origin is failing or only one destination.

Check whether Error Tolerance is enabled for the registered service and verify that at least one participating origin can return data successfully.

For metadata-related failures, verify the metadata-cache configuration and confirm that the participating destinations expose compatible service metadata.

If collection requests work but individual records fail, inspect the MOC key structure and SAP__Origin before investigating general connectivity.

If ODP reports a backend error, correlate the timestamp or transaction information with the corresponding SAP Gateway logs.

When MOC Is a Good Fit

Based on our experience, MOC is a strong fit when the same OData service is genuinely available from several backend origins, the application intentionally aggregates data from those systems, and the application understands origin-aware entity identity.

It is also a strong fit for applications already designed around backend-origin concepts and for collection-oriented workloads.

MOC can additionally be useful as a temporary development technique when one backend origin is unavailable while another provides equivalent test data.

When MOC Needs More Evaluation

I would evaluate MOC more carefully when a productive application normally uses only one origin, manually constructs OData entity URLs, relies heavily on single-record navigation, performs many entity updates or deletes, or has no concept of SAP__Origin.

In those cases, MOC may successfully return the initial collection data while changing important assumptions made by the consuming application.

What We Ultimately Chose

MOC was extremely valuable during our BAS troubleshooting.

It proved that BAS could reach OData Provisioning and retrieve real backend data without changing the productive default destination.

It also helped us understand the interaction between Error Tolerance, metadata caching, backend authentication and origin-aware entity identity.

However, once our normal user-aware runtime destination became available directly from BAS, MOC was no longer required as our primary local-development mechanism.

Our custom application had been designed against a normal single-origin OData contract. Retaining that contract for both development and production was simpler than introducing MOC-specific program changes solely for local testing.

We therefore retained MOC as a useful fallback, troubleshooting technique and architectural option rather than modifying the productive application unnecessarily.

Key Findings

MOC is activated through the service URL using ;<version>;mo. Without ;mo, OData Provisioning uses the default backend. Multi Origin Composition [https://he…6bfca.html]

MOC supports OData $batch requests. Multi Origin Composition [https://he…6bfca.html]

Error Tolerance allows successful-origin data to be returned when only some participating destinations fail. Multi Origin Composition [https://he…6bfca.html]

Metadata-cache configuration can materially affect MOC scenarios where one destination is inaccessible to the current caller.

MOC introduces origin-aware entity identity, which can affect custom applications that assume a single business key belongs to one backend.

Collection requests may work successfully while single-entity navigation fails because the application continues to construct the original single-origin entity key.

A custom application intended to fully support MOC may require program changes so that SAP__Origin is retained and used wherever the service requires it.

Navigation, updates, deletes and entity operations embedded inside $batch must also respect the MOC entity identity.

Applications already designed for multi-backend scenarios are naturally better candidates for MOC.

Error Tolerance is useful but should not automatically replace correct routing and authorization design. Support of multiple backend systems – How to use Multi Origin Composition and Routing [https://co…p/13280485]

ODP monitoring provides useful error and transaction information, but in our experience it did not provide a fully hyperlinked end-to-end trace. Detailed backend diagnosis still required correlation with SAP Gateway logs.

Conclusion

Multiple-Origin Composition in SAP OData Provisioning is much more than a switch that allows an OData service to query two backend systems.

It creates an origin-aware OData model intended to aggregate data from multiple backend systems while retaining enough information to identify the source of each entity.

For the right application, this is a powerful capability.

Our testing showed that MOC worked successfully for real backend collection data, searches, value helps, filtering and $batch processing while allowing us to preserve the productive default destination.

Error Tolerance and metadata-cache configuration were important parts of making that development scenario stable.

The main limitation became visible when our existing custom application addressed individual records using its original single-origin key syntax. Once MOC introduced origin awareness, those requests no longer contained enough information to identify the intended backend entity.

If MOC were to become part of the application’s productive architecture, the application would need to become origin-aware and use the complete MOC identity, including SAP__Origin where required.

For standard multi-backend scenarios such as SAP My Inbox, where origin information is already part of the application’s design, MOC is a much more natural fit.

For custom applications built around a single-origin contract, MOC remains extremely useful, but it should be treated as an application architecture rather than completely transparent routing.