In this Lesson, the Following Topics are Discussed:
- Adapter in an overview.
- Sample OData receiver adapter.
Adapter in an overview
A wide variety of pre-built adapters are available, with a differentiation made between input (transmitter) and output (receiver) adapters. These adapters support various application and transport protocols, as well as message protocols, and are configured based on their intended function. Adapters can be broadly categorized into two groups:
- TCP based.
- Non TCP based.
Often these adapters are also simplified called: HTTP based and non HTTP based.
Example: OData Adapter
Example: Details of an OData Adapter
|Atom Pub as XML or JSON representation
Overview of Available Adapters
You have the option to visit the help page or view the available adapters on an integration fow, based on your license, as demonstrated earlier with connectivity.
Read more here: Configure Adapter in Communication Channels
In case the current adapters do not meet your requirements, it is possible to import adapters from third-party sources.
Develop your own adapter
In case none of the aforementioned sources are helpful in finding the desired adapter, you can also create your own adapter.
Read more here: Developing Custom Adapters
Difference to the adapters in process integration
Within PI, every incoming message format is automatically transformed into the internal XI message protocol. Unlike cloud integration, there is no native format available. Essentially, this implies that if a binary format is used to send a message, it will be forwarded as such to the next integration flow component without any modifications. That's where converters come into play. Utilizing the XML Message format enables me to receive excellent support (XPATH) in individual integration flow components.
Sample OData Receiver Adapter
The OData adapter is utilized in the exercises. What sets the OData adapter apart, and why is it specifically selected for use in the exercise?
The Query Wizard
The OData Sender Adapter features a wizard that allows users to navigate to the interface to be accessed through the use of a metadata document. This approach makes it possible to configure the adapter even if the interface details are not fully known. However, this procedure is restricted to OData V2.0 and is only appropriate for a small hierarchy structure.
The Page Processing Mode
OData interfaces transmit data in the form of a feed utilizing the Atom Pub protocol, with namespaces and their respective prefixes used for added clarity.
In some cases, the number of entries in the feed can be quite substantial, potentially resulting in technical issues due to message size limitations. To overcome this challenge, paging processing is employed. This allows for the reading of the total quantity of entries in packages or pages, which are then processed sequentially. Nevertheless, this procedure requires an additional design decision.
Sample with Page Processing Mode
- No Page Processing
The Scenario has at No. 1, a looping Process Call. At No. 2, the OData Adapter calls a OData API.
The Result is:
- With Page Processing
Similar to the previous scenario, the OData configuration is situated below. In this instance, each call is expected to deliver only 5 items.
The Result is:
Automatically Removing of the Name Spaces of the Response
Apart from the option to gather data in packages, the name spaces and their prefixes are also automatically eliminated. This enables the data to be processed directly with XPATH. During the practice session, the HTTP adapter is utilized for the other calls. However, it does not automatically remove the namespaces, necessitating additional mapping.
Read more here: Configure the OData Sender Adapter
SAP provides a range of adapters in cloud integration, which vary based on their direction (inbound or outbound) as well as the transport, application, and message protocols employed. Broadly speaking, these adapters can be classified as HTTP-based, TCP/IP-based, or non-HTTP/non-TCP/IP-based. For instance, the OData receiver adapter offers several unique features, such as a wizard that facilitates easy configuration of the OData API to be called and the capability for page processing to handle large data volumes. Additionally, the adapter removes namespaces and their respective prefixes from the response, which is another significant advantage.