What are the applicable constraints to SAP NetWeaver Gateway 2.0?
This article contains several sections:
- General Constraints: These apply to SAP NetWeaver Gateway as a whole.
- Constraints for the software component versions IW_FND 240 and GW_CORE 190 that are available with SAP NetWeaver Gateway 2.0 SP4 are described in SAP we 1735987
- General Constraints for Generic Channel: These apply to the Generic Channel specifically.
1. BOR/RFC generator constraints: These constraints apply to the BOR/RFC generator if it leverages the generic runtime.
2. Screen Scraping constraints: These constraints apply to the Screen Scraping generator if it leverages the generic runtime.
3. Content: These constraints apply to some of the content that leverages the generic runtime.
The following constraints apply to SAP NetWeaver Gateway as a whole.
OData for SAP (standard mode): The implementation of the OData protocol "OData for SAP", provided with SAP NetWeaver Gateway 2.0 SP3, has the following constraints.
we that the constraints apply to the standard mode, as opposed to the compatibility mode for SP02.
Since a common library is used for both the Generic Channel and OData Channel programming paradigms, these constraints apply to SAP NetWeaver Gateway as a whole.
Do not use objects in the /IWCOR/ namespace. Only use official APIs.
JSON format is only supported as of SP4.
BOR/RFC and Screen Scraping generator do not support OData $expand functionality.
BOR/RFC and Screen Scraping generator do not support OR and AND operators in $filter expressions.
No POST, PUT, DELETE, MERGE on navigation path.
Updates are only allowed on the canonical URI. Reason is that the semantics are not clear. What do you modify? The association? The target entity? Both?
POST possible as of SP4. Here the assumption is that you create both the target entity as well as the association.
No support for link manipulation requests: Link manipulations according to OData specification, that is the addition or deletion of a link to an entry of an associated EntityType, are not supported.
Example: DELETE /OData/OData.svc/Categories(1)/$links/Products(10) HTTP/1.1
No support for MERGE requests: MERGE requests according to OData specification, that is the updating of a runtime-defined subset of the properties of an entry only and leaving the others untouched, are not supported.
No support for the following query options:
$skiptoken, i.e. Next links for server-driven paging
(NEW: $skiptoken is supported but in the inlined data no next link must be used. Make sure to retrieve all data in the inline case)
$inlinecount, i.e. instructing the server to include a count value for all entries matching the given filter criteria
(NEW: is supported as of SP04)
$select is generically resolved by SAP NetWeaver Gateway and enabled for consumption, i.e. specifying a subset of the properties of an EntityType (example: only return Name and Lastname properties of customer entries, excluding all other properties from the feed of customers). The parameter is not populated to the application.
(NEW: is supported as of SP04)
- At this time, only the logical operators 'eq','ne','le','lt','ge','gt' are supported.
- OData filter expressions cannot be completely translated into ABAP selection options. As a result the following constraints apply: startswith, endwith is not supported.
- No support for HTTP Header fields
- There is no support for content type negotiation or capability negotiation via Accept and MaxDataServiceVersion HTTP header fields.
PUT POST constraint
If a PUT or POST call is used all properites of the entity have to be provided within the request body. Some of the properties can remain empty, but have to be present. This restriction is resolved with SP4.
(SP5 onwards) Subscription
Multiple origin composition is only supported in subscription management for administrators.
If you are using SAML 2. 0 authentication and you would like to use different versions in the URL e.g. ";v=2" these path segments might get lost in certain scenarios. As described in SAP we 1785499 the underlying SAP_BASIS component needs a certain we level where this issue is either fixed or can be fixed via that SAP we.
SAP NetWeaver Gateway Service Builder
(SP4 onwards) General:
- Service Builder supports OData V2.0 and is not a tool for 100% code generation based on spec.
- It is not possible to maintain versions in the Service Builder
(SP4 onwards) Mass-Edit View: Referential Constraint
- It is not possible to assign principle/dependent entity at referential constraint. It is picked up from the same assignment done at Association level.
(SP4 onwards) Wizard: Import file
- For max length field only numbers are considered, alpha numeric values are ignored, e.g. MAX
- It is not possible to re-import the same edmx file to enhance the current model while preserving the changes done already in the Service Builder
(SP4 onwards) MPC generation:
- ABAP Field Name of properties cannot be the same as ABAP pre-defined data types, e.g. STRING, DATS, etc
(SP5 Onwards) Wizard: Import RFC/BOR Interface
- If an entity is created from RFC/BOR interface the DDIC assignments are not copied over. Once an entity gets created from an RFC/BOR it is not possible to enhance the same by adding more artifacts from the same source in the next iteration.
- A Function module interface having a table type other than access mode "Standard" cannot be used while generating DPC with target system as "Local".
(SP5 Onwards) Data Source Mapping
Restrictions for operations - The following OData features are not supported by the generated DPC and need to be implemented manually
- Any handling of Media resources
- $batch with changeset handling. Batch calls without using changeset are supported.
- Patch / Merge
- Deep Insert
The following options are not supported in query operation
Association handling - the BOR/RFC generator supports associations between entities in the same service if the following terms are met:
Principle entity cardinality must be 1
Referential constraints are defined for all key properties of principal entity
Navigation property is defined for the principal entity. Navigation from dependent entity to principal entity is not supported (NEW: such navigation is supported as of SP07)
In case of 1:N relationship, from principal to dependent entity, the query operation in the dependent entity must be mapped to a data source (BOR or RFC) and the right properties (as defined in the referential constraints) must be mapped to input parameters of the data source.
Supported nested levels - When mapping an entity to a data source (BOR or RFC) the following levels of structure nesting are supported: The Service Buider supports the following mapping complexity:
f = Simple field
S-f = field in structure
T-f = field in table
S-S-f = field in structure within a structure
S-T-f = field in table within a structure
T-S-f = field in structure within a table
Further nesting levels are not supported.
Mapping a table is supported only in case the table has a line type. Tables with predefined type (e.g. string) or with reference type are not supported.
(SP5 Onwards) Wizard: Redefine GW service
It is possible to redefine only services developed using pure OData Channel (IW_BEP)
(SP5 Onwards) Wizard: Include GW service
It is possible to include only services developed using pure OData channel (IW_BEP)
It is not possible to define navigation property on entities from included service within the Service Builder
(SP4 Onwards) Wizard: SPI
The Gateway service generator is skipping the nodes of SPI objects due to named includes. If a node contains a named include these entities which are having the named includes will be ignored, but the service will still work with the remaining entities
(SP4 onwards) BW integration via MDX
- Query response containing more than 1 million records is not supported
- Hierarchy is not supported
- Navigation from result entity to value help is not supported
- Variables should have only single values or intervals
- No formatted measure values
- No currency for amount key figures, no unit for quantity key figures
- No counting of entity instances in result
(SP4 onwards) GenIL integration
- Currently, the CUD (create, update, delete) operations are not supported on the related objects
- Dependent objects which are assigned as related objects to more than one root/access/dependent object in the GenIL model are not supported
- Each root/access object is assigned one default query during generation, which can be changed by the application developers after generation
- Filtering is supported only for those properties of an entity (corresponding to the root/access object) which has a similar named field in the attribute structure of the default query
(SP4 onwards) HANA integration
The technical constraints of the SAP NetWeaver Gateway with SAP HANA Integration are described in the SAP Online Help:
ABAP authorization objects can only be maintained in upper case. HANA artefacts are case-sensitive.
Considering enhancements of components, the same restrictions apply for access to the HANA database as are in place for the ADBC application interface. For example, parametrization of SQL statements is not supported for special access with PLACEHOLDER(n) for calculation views or stored procedures.
No associations are generated. Therefore, no generic mapping of navigation paths are available. Associations can only be implemented via enhancement/redefinition of standard providers.
From the HANA system no texts for metadata are generated.
The following query functions are not supported:
$batch is only supported generically for read operations
$expand -> see Assosiations
Links and streams are not supported.
Supported query functions:
$filter with restrictions
$select (automatic generation of aggregations for measures)
OData for SAP (compatibilty mode)
Deep insert (fixed with SP02)
Deep insert according to OData specification, that is the inlining of an associated entry (which can, theoretically, have inlined entries itself) to be created in conjunction with the sorrounding entry, is not supported. Example: create a purchase order with a purchase order item in one request. Consequently, in the BAPI/RFC Generators, you cannot map structure or table input parameters to data objects below the root, even if these are mandatory for calling the respective BAPI/RFC. Alternatively, you can map (i.e. flatten) the fields of a structure parameter to the properties of the root data object or assign custom constant values to them.
There is no workaround for table input parameters, i.e. respective BAPIs/RFCs cannot be used.
- Batch requests (available with standard mode in SP03)
- Batch requests according to OData specification, that is the bundling of multiple OData operations into one multipart HTTP request and hence indicating a transactional bracket, are not supported. Example: withdraw amount from account 1 and book to account 2 in one transaction.
- No support for system query options
The following OData system query options are not supported: $expand, i.e. inlining of associated entries (fixed with SP02).
Conversion of Unit Quantity and Currency Amount
The gateway framework provides a default conversion of unit quantity without rounding and based on the customizing for the currently used unit-of-measurement in DB table T006 (field ANDEC and DECAN). The default conversion takes care of the following 4 rules:
- Output is the same as input if the unit-of-measurement is not customized in DB table T006.
- No decimal digits lost if not zero
- Delete zero's if input decimals > max(ANDEC,DECAN)
- Output is the same as input if input decimals < max(ANDEC,DECAN) because DDIC should also have higher priority!
- From SP09 onwards, a provider application can define its own conversion by using the metadata API to overrule the default conversion.
The gateway framework uses the IDOC conversions as default for currency amount. The IDOC conversion requires, however, that the input must have exactly 2 decimal places.
Until SAP NetWeaver Gateway 2.0 SP08, a provider application has to disable the framework conversion and to do its conversion by itself before return the result to the gateway framework.
From SP09 onwards, it is available to define an own conversion exit for inbound and outbound by using the metadata API above.
Soft-state processing mode on the SAP NW Gateway
Currently URLs containing segment parameters such as ‘;mo’, ‘;o=’, ‘;v=..’ cannot be processed in the soft-state processing mode as the path-attribute of the context-id cookie sent to the client must not contain a ‘;’. This kind of URLs are always processed in the stateless mode by the GW framework.
ABAP domains starting with XSD must not be used for SAP Gateway service artifacts
- ABAP data types based on ABAP domains starting with ‚XSD‘ must not be used for modelling of gateway service artifacts, e.g. properties. Usage of these domains causes runtime errors.
- XSD types are used in ESOA scenarios. These types cannot be supported by the Gateway framework. As a mitigation developers have to map XSD types in their service implementation to other domains before sending the data to the SAP Gateway framework.
General Constraints for the Generic Channel
The following technical constraints apply to multiple components of the Generic Channel.
The following constraints apply to the content generators, which are based on the Generic Channel programming paradigm:
- $orderby, i.e. specifying a sort order for feeds based on the properties of the respective entity type
- The generators do not support complex types in the Gateway data model structure.
- Language-dependent labels from DDIC (ABAP Dictionary)
- There is no DDIC-reference support for the dynamic retrieval of language-dependent labels in conjunction with the generators. That is, the BOR and RFC generator will replicate these labels to the SAP NetWeaver Gateway system in the user's logon language. Consequently, these labels must be translated in the SAP NetWeaver Gateway system as required.
No support for OData concurrency
Concurrency handling according to OData specifications (via optimistic locking based on ETags) is not supported.
Restricted support for FC_ attributes
At present, only FC_TargetPath (specifies the target element or attribute to contain the respective property value in the feed output) and FC_KeepInContent (specifies that a property shall be present both in the content section of an entry as well as at the place sepcified by FC_TargetPath) are supported at property level. Consequently, you can only use standard values for FC_TargetPath because custom elements or attributes would require setting FC_NsPrefix and FC_NsUri as well. (Cf. section 188.8.131.52.2. 1 of the OData spec for more details)
Restricted support for service operations, that is, function imports
You can only use data objects (that is, nodes in Gateway metadata) for the input and output of operations. According to OData spec, simple types and complex types would also be allowed as the output of function imports.
- The key fields of root data objects must adhere to components of structured type /IWFND/S_COR_ID.
- /IWFND/S_COR_ID-VALUE, i.e. the component for the actual key value, is limited to 72 characters.
- Key fields must be fully inherited from parent data object to child data objects.
Due to the S_COR_ID constraint, if a data source has multiple key parameters, the generators concatenate their values to /IWFND/S_COR_ID-VALUE in the following way:
This will not work if the resulting string exceeds the 72 character-length restriction of /IWFND/S_COR_ID-VALUE however.
Deletion of Customizing entry
Deletion of Customizing entry for GSDO type assignment to GSDO group is not automatically added to a transport when deleting a generated data model.
The foreign key in the source data object of a to-one relationship may only consist of exactly 1 field, and must not exceed the total supported length of /IWFND/S_COR_ID-VALUE (currently 72 characters). As a workaround for the 1-field constraint, the BAdI /IWFND/BD_IFL_MAP_1_TO_1_LINK can be implemented to handle concatenation of multiple fields into /IWFND/S_COR_ID-VALUE.
Type mapping constraint (BOR, RFC, Screen Scraping)
- It is not possible to map the property of a Gateway data object to a data source field of a deviating type (strict type enforcement).
- Key mapping constraint for READ (BOR, RFC, Screen Scraping)
- When mapping the READ operation for a data model, you have to map all data source input parameters to the root key property (/IWFND/S_COR_ID-VALUE), or use constant value assignments.
Manual definition of key concatenation order (BOR, RFC, Screen Scraping)
By default, multiple data source fields mapped to the root key property /IWND/S_COR_ID-VALUE are concatenated in alphabetical order based on the field names. If the field names deviate across the data sources used for mapping the different operations of a given data model, the user has to validate and adapt the field concatenation order manually to ensure it is consistent for all operations.
Read in conjunction with Create/Update (BOR, RFC, Screen Scraping)
Create operation always triggers a subsequent Read operation, Update is always called in conjunction with a preceding Read. It is not possible to override this in the tool.
System alias usage
The system alias used when creating a data model must be configured in all systems into which this data model is being transported. Whilst it might point to different physical destinations, the name must be the same. If you do not maintain the system alias in all systems, you will not be able to open the data model from the generator tool in the affected systems.
BOR/RFC Generator constraints
BAPI_TRANSACTION_COMMIT is always called in the BOR generator when using Create/Update/Delete operations (that is, provided that no errors arise). It is not possible to override this in the tool.
- Structure and table types used for fields of table data source parameters are not supported.
- we: This should only affect plain RFCs, as BAPIs should not expose such deep parameters.
Screen Scraping constraints
The Screen Scraping generator uses dynpro screens as a data source. The more dynamic the screen is, the less stable the screen scraping service built upon it will be.
Screen elements not supported by Screen Scraping:
All EnjoySAP controls, i.e. ActiveX controls such as ALV, Tree, HTML, Picture, text editor, and so on.
ABAP lists typically generated in reports and selection dialog boxes.
Search helps are used by the Screen Scraping generator as data source provider for query operations. The search help definitions are retrieved from the ABAP Dictionary. A constraint for this approach is that it cannot support search helps that are provided locally on the screen (using ON VALUE REQUEST command). It can only support search helps that are defined in SE11.
- Table controls can be used with the Read operation only. Currently, it is not possible to update/create/delete table entries.
- Screen Scraping uses the page-down button to scroll through tables and retrieve all their entries. If no page-down button is provided on the screen, only the first rows visible on the screen can be retrieved.
- Time information passed to fields of type EDM.DateTime are not considered, only the date information is processed. Additional fields for time are provided wherever required.
- Partial content of an error messages will not be displayed in the logon language.
- After a leave request has been approved and posted to the infotype, further modifications are not permitted by OData services.
- Codelist is intended only for the exposure of value helps that do not have a foreign key relationship. For example, CodeList capabilities can be used to get country codes and their descriptions.
- However, this cannot be used for region codes since region codes have a relationship to country codes.
Consumers will not be able to determine the inline entry (ReportResult collection) by looking at the ReportResultNotification collection in the metadata.