WHINT WebDAV Adapter (On-Premise)

Functionality

This JCA Adapter for SAP PI / SAP Process Orchestration (PRO) supports the WebDAV protocol (Web-based Distributed Authoring and Versioning) which is based on http(s) and allows read/write access to any WebDAV provider that implements the protocol, such as e.g. Telekom MagentaCloud, Box.com, ownCloud, … 


Prerequisites

  • Works with SAP PI 7.1 and higher (incl. SAP Process Orchestration 7.50)
  • Deploy the SCA file provided by Whitepaper InterfaceDesign using NWDS/JSPM/SUM/Telnet
  • Import the TPZ file provided by Whitepaper InterfaceDesign into the ESR

Usage

  • Create a new sender or receiver communication channel and select the adapter “WebDAV” from namespace “http://whint.de/xi/WDA” (Software Component WHINT_WDA 2016.04 of whitepaper-id.com)
  • Transport Protocol: WebDav / HTTP
  • Message Protocol: File
  • Other Options
    • URL (http/https)
    • Proxy (optional)
    • Authentication (Username/Password)
    • Filename
    • Directory
    • Set/Use Adapter-specific Message Attributes (ASMA)
      • Namespace: http://whint.de/xi/WDA
      • FileName
      • Directory
      • Size (sender only)
      • Timestamp (sender only)
      • Host (sender only)
    • Sender Only
      • Poll-Interval in seconds (Sender)
      • Delete file (Yes/No)
      • Duplicate file checking (Yes/No)
      • Quality of Service (EO/EOIO)
      • Archiving on WebDAV Server (Directory/Filename)

Example

WDA1

WDA2

 

How to integrate with Microsoft Azure Service Bus using WHINT AMQP Adapter

This article describes the necessary steps you have to perform to connect with Microsoft Azure Service Bus using WHINT AMQP Adapter (On-Premise).

Azure Service Bus is a generic cloud-based messaging platform that enables you to send data asynchronously between decoupled systems – applications, services and devices – wherever they are.

For the message exchange component types are connected into processing chains within the service bus. The following components are actually supported by the WHINT AMQP Adapter.

  • Service Bus Namespace – A namespace provides a scoping container for addressing Service Bus resources within your application.
  • Service Bus Queue – A Service Bus queue is an entity in which messages are stored.
  • Service Bus Topics and Subscriptions – A topic can be visualized as a queue and when using multiple subscriptions, it becomes a richer messaging model, essentially a one-to-many communication tool.

(Source: https://azure.microsoft.com)


Publishing
Messages send to the SAP PI Adapter framework are published asynchronously to the message broker by an AMQP receiver communication channel.


Consuming
Asynchronously, a message consumer (receiving application) pulls the message from the queue and processes it. The producer does not have to wait for a reply from the consumer in order to continue to process and send further messages. Queues offer First In, First Out (FIFO) message delivery to one or more competing consumers. That is, messages are typically received and processed by the receivers in the order in which they were added to the queue. A sender communication channel is used to connect with the specified queue/topic and consume messages.


How-To: Create Service Bus

Create Namespace (New->Enterprise Integration->Service Bus)

AMQa1

AMQa2

The namespace is created.


How-To: Integration via Queues

The AMQP adapter does not support partitioned queues, so make sure that the option “Enable partitioning” is set to false when creating a queue on Azure Service Bus.

Create Queue:

AMQa3

Add Shared access policy (credentials):

AMQa4

AMQa5

Display Policy and copy Key:

AMQa6


How-To: Send to Queue

Configure Receiver Channel:

AMQa7

AMQa8

Create iFlow/Integrated Configuration (e.g. with Dummy Interfaces):

AMQa9

Test iFlow/ICO:

AMQa10

AMQa11

Monitoring (PI/PRO):

AMQa12

AMQa13

Monitor/check queue in Azure:

AMQa14


How-To: Integration via Topics

Create Topic:

AMQa15

Also create a Shared Access Policy (see above for queues).


How-To: Send to Topic (publish)

Configure Receiver Channel:

AMQa16

Create/Change iFlow/ICO and send message.

Monitor/check queue in Azure: Topics are using a Publish & Subscribe mechanism (Pub-Sub), so when there is no subscriber to a topic, the message is successfully transmitted, but not visible. So in order to see a successful transmission, we also consume the message topic by creating a AMQP Sender Channel that subscribes to the topic.


How-To: Receive Topic (consume a subscribed topic)

Azure: Create Subscription

AMQa17

AMQa18

Configure Sender Channel:

AMQa19

Send message (again).

Monitoring (PI/PRO):

AMQa20

AMQa21

 

WHINT AMQP Adapter (On-Premise)

Functionality

This JCA Adapter for SAP PI / SAP Process Orchestration (PRO) supports the Advanced Message Queuing Protocol (AMQP), a reliable way to establish a properly decoupled application integration using message queues and topics. AMQP defines both the network protocol and the server-side services through a defined set of message capabilities called AMQ model, which consist of a set of components that route and store messages within the broker service and a network wire-level protocol, that lets client applications talk to the server and interact with the AMQ model it implements.

It connects asynchronously to the followings Brokers by sending and receiving messages in a reliable way:

  • Microsoft Azure Service Bus (Cloud)
  • RabbitMQ (On-Premise/Cloud)

Prerequisites

  • Works with SAP PI 7.1 and higher (incl. SAP Process Orchestration 7.50)
  • Deploy the SCA file provided by Whitepaper InterfaceDesign using NWDS/JSPM/SUM/Telnet
  • Import the TPZ file provided by Whitepaper InterfaceDesign into the ESR

Usage

  • Create a new sender or receiver communication channel and select the adapter “AMQP” from namespace “http://whint.de/xi/AMQ” (Software Component WHINT_AMQ 2016.04 of whitepaper-id.com)
  • Transport Protocol
    • Select one of the following transport protocols
      • MS Azure – to connect with a Microsoft Azure Service Bus
      • RabbitMQ – to connect with a RabbitMQ Broker
  • Message Protocol
    • The message procotcol is preselected based on the transport protocol. The following are available so far:
      • AMQP 1.0 – This is the message protocol for MS Azure
      • AMQP 0-9-1 – This is the message protocol for RabbitMQ
  • Other Options
    • Host & Port
    • Virtual Host (RabbitMQ)
    • SSL/TLS enabled
    • Queue / Exchange Name
    • Topic Support
      • Subscription ID (MS Azure)
      • Exchange Type: direct/headers/fanout/topic (RabbitMQ)
      • Routing Key (RabbitMQ)
    • Consuming Interval (secs/msecs)
    • Authentication based on User/Password
    • Quality of Service (EO/EOIO with queue name)
    • Set/Use Adapter-specific Message Attributes (ASMA)
      • Namespace: http://whint.de/xi/AMQ
      • externalMessageID – Message Id received from broker
      • CreateDateTime – Timestamp of message creation
      • QueueExchangeID – Name of the Queue / Exchange Name
      • RoutingKey (only RabbitMQ)

Example

AMQo1

AMQo2

AMQo3

WHINT AdapterEngine Switcher

WHINT_AES_Standard

 

Functionality

We can use Decentral Adapter Engines to separate runtimes and isolate scenarios, which is great.

To minimize planned downtimes (maintenance/deployment), it could be good to switch all message processing to one Adapter Engine and perform the maintenance of the other Adapter Engine.

This can be achieved with the WHINT AdapterEngine Switcher, which is using the Integration Directory API and the SAP Web Dispatcher.

 


Prerequisites

This scenario works ideally with Single Stack (SAP Process Orchestration), but is also supported for SAP NetWeaver Process Integration (PI), version 7.1 and onwards. However, only the Java Channels will be affected during the switch as only the Adapter Engine (Java) is being switched.

An SAP Web Dispatcher is needed for all senders using push mechanisms, such as SOAP, HTTP, REST, AS2 – where an URL is used to call the channel by the message sender/client. This makes sure, all clients do not have to change the URL when the Adapter Engine is switched.

The solution is imported as as ESR content (tpz file) and configured in the Integration Directory afterwards.


Usage

There are 3 switch modes available which are selected from a HTML form:

  • Standard: Both Adapter Engines are in use, however only one Adapter Engine is processing push calls from SOAP/HTTP/REST
  • Central: Only the Central Adapter Engine is used, the Decentral AE can be patched
  • Decentral: Only the Decentral Adapter Engine is used, the Central AE can be patched

After selecting the switch mode, the changes have to be activated through a change list in the Integration Directory.

Central Switch Mode:

WHINT_AES_Central

Decentral Switch Mode:

WHINT_AES_Decentral


Example

will follow soon