SAP Process Integration Connectivity Add-on 2.0
I am happy to announce the general availability of SAP Process Integration Connectivity Add-on 2.0 as of December 23, 2020. The add-on includes SFSF adapter for seamless integration with SAP SuccessFactors systems (supporting SFAPI, OData V2 API and LMS REST APIs), and OData adapter for integration with SAP, third party and custom built OData V2 services. Connectivity Add-on 2.0 runs on SAP Process Orchestration 7.5, taking advantage of the latest improvements in the product.
New Features and Enhancements
- New Feature: OData adapter available on sender side as a polling adapter
- New Feature: Dynamically setting OData resource path
- New Feature: Batch processing in SFSF adapter
- New Feature: Support of Adapter-Specific Message Attributes
- New Feature: Sending dynamic HTTP headers
- New Feature: Channel level configuration of connection timeout parameters
- New Feature: Channel level HTTP traces
- New Feature: OData metadata caching
- Enhancement: Extending the scope of dynamically evaluated dates
Let’s take a closer look at the new stuff.
OData sender adapter
Until now, OData adapter was somewhat incomplete as it could be configured only on receiver side. With Connectivity add-on 2.0, OData adapter can also be configured on the sender side as a polling adapter (similar to SFSF adapter). Here is a list of the main features of OData sender adapter:
- Query (GET) and Function Import as OData operations
- Support of Exactly Once (EO) and Exactly Once In Order (EOIO) quality of service
- Paging of the response from OData service
- Configuration of the maximum number of records to be included in a single XI message
- Support of Adapter-specific message attributes
For more information check Configuring OData Adapter Sender Channel and SAP Note 2907730.
Dynamically setting OData resource path
In Connectivity add-on 1.0 you were able to provide some parts of the OData resource path dynamically. For example, when performing query on receiver side, it was possible to pass some System Query Options ($top, $skip, $filter) and custom URL parameters dynamically using the QueryStringOptions data type. The dynamic evaluation of dates feature also added to the dynamic nature of the queries. These features are useful but not universal – QueryStringOptions allows passing dynamic parameters only for Query operation and it was possible to change only the query part of the URL but not other parts.
We have addressed these limitations in Connectivity add-on 2.0. In both SFSF and OData adapter it is now possible to set the entire OData resource path (not just the query part) dynamically. This is available for all operations not just for Query. For Query operation, the QueryStringOptions data type has been extended to allow setting the resource path. For all other operations, the adapters make use of a new feature introduced in this release – adapter-specific message attributes. With these changes, you can change any part of the resource path, for example – the entity, the key predicate (for Read operation) etc.
For more information, check SAP Note 2547946.
Batch processing in SFSF adapter
SFSF adapter (in OData mode) did not have support for batch processing as this was not supported by SuccessFactors OData API. As there is already support for $batch operations on SuccessFactors side, we also introduced batch processing in the adapter. The functionality is identical to the batch processing in OData adapter.
For more information, check SAP Note 2904345.
Support of Adapter-Specific Message Attributes
OData and SFSF adapters now support Adapter-Specific message attributes (ASMA). They can be used in sender channels to propagate channel configuration parameters to XI message headers, which can then be used to make routing decisions, in mappings etc. Receiver channels also support ASMA. Using ASMA in receiver channels, you can dynamically set the OData resource path, as well as pass dynamic HTTP headers.
For more information, check SAP Note 2935373.
Sending dynamic HTTP headers
OData adapter and SFSF adapter in OData mode set required HTTP headers by default. Custom HTTP headers can be configured in the Advanced Settings of the channel (refer to SAP Note 2590026). The custom HTTP headers, configured in the Advanced Settings, are static, that is, the value is hardcoded and cannot be changed. With Connectivity add-on 2.0, it is also possible to set dynamic HTTP headers. You set them as Adapter-Specific Message Attributes in the XI message. This makes it possible to set HTTP headers, containing dynamic and message-specific values such as identifiers, tokens, timestamps, etc.
For more information, check SAP Note 2959614.
Channel level configuration of connection timeout parameters
In addition to the global connection timeout parameters that are set on adapter level (in the adapter application properties) and are applicable to all channels, in Connectivity add-on 2.0 it is possible to set these parameters on channel level, effectively overriding the global values.
For more information, check SAP Note 2937008.
Channel level HTTP traces
This feature brings value to the supportability of the Connectivity add-on adapters. It makes it easier to spot some issues by collecting HTTP traces only for the affected channel(s). The traces for each channel are written to a separate location.
For more information, check SAP Note 2947356.
OData metadata caching
The OData service metadata is cached on the local file system, making it faster to load. This brings performance benefit especially when the service metadata is large in size (as is the case with SuccessFactors OData API). Some OData services (e.g. SuccessFactors) support the ETag HTTP header which makes caching more efficient – the cached service metadata is updated only when there are changes in the metadata on the server. For OData services that do not support the ETag header, the metadata is cached for a specified period (configurable). It is also possible to force a metadata reload if needed.
For more information, check SAP Note 2947930.
Extending the scope of dynamically evaluated dates
SFSF sender channels could dynamically evaluate dates in the query for quite some time. This feature is no longer restricted to SFSF sender channels. It is now available in both SFSF and OData adapters and for both sender and receiver channels. On the receiver side, it can also be combined with the dynamic query option (for OData protocol).
For more information, check SAP Note 2995887.
In this blog post we had a brief overview of the new features and enhancements in SAP Process Integration, connectivity add-on 2.0. Follow SAP Process Integration, connectivity add-on tag for more interesting blogs regarding Connectivity add-on, including more details about the new features and sample scenarios configuration.
Thanks for writing blog on the CONNECTIVITY ADDON. Hope this is finalized version and customers can install without any Issue.
Yes, it is production ready 🙂
After installing ADD-ON 2.0 in SAP PO DEV, all the SFSF receiver channel went into below error message:
Channel failed to start due to com.sap.aii.adapter.sfsf.ra.xi.channel.config.ChannelConfigException:
CHANNEL_CONFIG_ERROR:Incorrect channel configuration for SF channel SFSF_RCV_XXXXXX:
Reason is: com.sap.aii.af.service.cpa.impl.exception.CPAObjectException:
Value with name oDatabatch not available
My understanding is that the existing channels shouldn't get disturbed after installing 2.0.
Our SAP PO DEV is on 7.5 SP18.
Hi Naresh, thank you for trying out the new release. You're absolutely correct - existing channels should not be affected. This is fixed with SAP Note 3010101.
Thanks a lot Ivo for releasing the fix so quickly.
One more observation with SFSF sender channel. Processing log of the SFSF sender channel always says "New XI message containing 0 records has been sent to Module Processor" even though it fetches data from SF. Can you pls check why?
Hi Naresh, may I ask you to open an incident in BC-XI-CON-SUF component and ask for it to be directly routed to dev team? Let the colleagues know that you're already in contact with me.
There were some improvements we've made initially to the channel logs for OData protocol. The same improvements are now implemented for the other protocols and you should see the correct numbers.
DeltaSync parameter looks not working on CONNECTIVITY ADDON 2.0. It is giving "SFAPI domain error". The same is working on CONNECTIVITY ADDON 1.0. Just logged a ticket with SAP on this. Pls check.
Hi, thank you very much for this blog!
We are trying to implement "API's" using SAP PO. The idea is to expose REST Senders and consuming oData Services from S4, because the client does not want to publish the OData as well.
I have a question for you, because there's something that I cannot understand and I couldn't find the response.
To be honest I was wondering about the Operations Modeler Tool. It won't be updated to use with Oxygen?
For example right now I'm working with SAP PO 7.5 SP16 and NWDS of the same version, so to work with the Operan Modeler I have to install Kepler, download the tool, import the OData model, export it as XSD and import it in the 7.5 ESR?
Yes, currently this is the way to model OData and SFAPI operations. We are working to integrate the Operations Modeler in NWDS so that you can model your operations in the same IDE that you use to configure your scenarios.
Great! Thank you very much.
Hello Sebastian Alvarez / Ivaylo Manasiev ,
We are exactly facing same issue. We are also using SAP PO to implement "API's" to expose REST Senders and consuming oData Services from S4. We are facing challenge with XSD generation as currently Operations Modeler is not available in NWDS.
Can you please suggest workaround?
Hi Siddharth Shah you have two ways to do it.
1- Using a CPI and importing the ODATA Model, then there you can check to generate the XSD and that's it.
2- If do not have access to any CPI environment, check this Documentation https://help.sap.com/viewer/307cdb0f1a69422bb23b9ee426bd39f7/1802%20YMKT/en-US/777c719c287049398225ef55f7bf44ed.html
Unfortunately I couldn't find another way to do it.
We have updated to connectivity add on 2.0 patch 7 and we are getting below error.