WHINT MessageMissing Alert

Functionality

How can we make sure if a message was processed at all with SAP PI/PO? Today, no alert means no error.
But what if the sender system did not place the file or send the message? You will find out, when the business will ask for missing data…
WHINT MessageMissing Alert is a solution that runs pro-actively as a job on your system (e.g. every hour during business hours or every month on the first) and checks in the message (performance) monitor if the interface ran or not. In case no message was found, an e-mail will be sent to a receiver.


Prerequisites

  • Works with SAP NetWeaver PO (PI single-stack) version 7.3 EHP1 and higher (including 7.50)
    • If you read from more than one Adapter Engine and you enforce SSL, you need to apply SP15 for 7.31 / SP10 for 7.40
  • Create a new User with the following standard role (or equivalent custom role): SAP_XI_MONITOR_J2EE
  • Activate the performance monitoring in NWA
    • Configuration > Infrastructure > Java System Properties
    • Services > XPI Service: AF Core
    • Properties > profile.performance.runtime = true
    • Configure the interval to keep the last 31 days of the message processing by executing the following URL on your PI/PO system: http(s)://host:port/mdt/performancedataqueryservlet?PeriodConfig=DAILY=31
  • Import the Software Component into your ESR provided by Whitepaper InterfaceDesign
  • Deploy the SCA/EAR file provided by Whitepaper InterfaceDesign using NWDS/JSPM/SUM/Telnet
  • Configure the Scenario by installing the Integration Scenario in NWDS (via iFlows) or in Integration Directory Swing Client. Per default “WHINT_MMA” is defined as the sender business component.

MMA1


Usage

  • Schedule the job from NWA -> Operations -> Jobs -> Java Scheduler
  • Add Task with Job name MessageTriggerJob
  • The solution is using WHINT MessageTrigger Job which can generically send an XML message to the PI/PO runtime.
  • Parameters:
    • ScenarioID: WHINT_MMA (actually this value can have an
    • ScenarioSender: MMA_TEST1 (this value has to match the IntegratedConfiguration/iFlow configuration)
    • Param01: Interface=<the interface name of the message you look for. “*” is the wildcard.>
    • Param02: InterfaceNS=<the interface namespace of the message you look for. “*” is the wildcard.>
    • Param03: SenderComponent=<the sender system of the message you look for. “*” is the wildcard.>
    • Param04: SenderParty=<the sender party of the message you look for. This parameter is optional.>
    • Param05: ReceiverComponent=<the receiver system of the message you look for. “*” is the wildcard.>
    • Param06: ReceiverParty=<the receiver party of the message you look for. This parameter is optional.>
    • Param07: Period=<DAY/HOUR/15MIN>
    • Param08: Frequency=<e.g. the amount of hours within the message was processed>. Possible values / Unit:
      • DAY: 1..31
      • HOUR: 1..24
      • 15MIN: 1..4
    • Param09: EmailRecipient=<E-Mail Address or list: receiver1@company.com;receiver2@company.com>
  • The sequence of the parameters is not important.
  • The scheduling should be done according to your business needs (hourly, Mon-Fri between 8:00 and 18:00)

MMA2

MMA3


Example

Finance data for reconciliation from a payment service provider shall be sent monthly from an SFTP server and posted into SAP accounting. The solution makes sure that the interface is running every month at least once or at a given day.

Another example is that the warehouse interface shall be active during business hours. Stock movement messages should be sent at least once every 30 minutes from SAP ERP to the AS/400 warehouse system. An immediate alert is sent out if no messaging takes place.

MMA4


 

WHINT RemoteDirectory Checker

Functionality

This Adapter Module is checking for a file (e.g. blocker) at a remote location. When the file is found, the processing of the communication channel (of any type running on the Adapter Engine) is stopped. The solution is useful e.g. if you want to avoid the transfer of files if the target directory is not empty.


Prerequisites

  • Deploy the SCA/EAR file provided by Whitepaper InterfaceDesign using NWDS/JSPM/SUM/Telnet
  • Check if the deployment was successful in JNDI browser (NWA -> Troubleshooting -> Java -> JNDI Browser) It should appear under Folder WHINT with name RemoteDirectoryChecker

Usage

  • Add the Adapter Module in the Module Processor (Sender or Receiver Channel)
  • Name: WHINT/RemoteDirectoryChecker
  • Type: Local
  • Parameters:
    • FileName: name of the file or pattern (e.g. blocker.txt or *.trg)
    • Directory: folder of remote server or NFS
    • URL (optional): the address of the remote location in case of FTP or SFTP (SSH) (s)ftp://host:port
    • User (optional): login for (S)FTP server
    • pwd (optional): password for (S)FTP server
    • HostProxy (optional): FTP proxy host (e.g. SOCKS5)
    • PortProxy (optional): FTP proxy port
    • UserProxy (optional): user for proxy
    • pwdProxy (optional): password for proxy

Example

Here, a File is transferred from one location to the other if the target folder is empty

Channel Configuration: 

coming soon

WHINT MessageTrigger Job

Functionality

In case you want to start an interface without scheduling a polling sender adapter (e.g. file) and you need a reliable trigger for a message transfer, this solution helps to set up any scenario easily. An XML message with a generic structure is sent to the messaging runtime with the parameters you have defined in the trigger job. Based on the parameters you can proceed with any interfacing scenario (call a web service/REST/HTTP URL, read a file using WHINT FileReader Adapter, …).


Prerequisites

  • Deploy the SCA/EAR file provided by Whitepaper InterfaceDesign using NWDS/JSPM/SUM/Telnet
  • Define an Integrated Configuration (ICO) or iFlow that reflects the scenario

Usage

  • Schedule the job from NWA -> Operations -> Jobs -> Java Scheduler
  • Add Task with Job name MessageTriggerJob
  •  Parameters:
    • Scenario: <name/description of the scenario>
    • System: WHINT_MTJ
    • Further scenario parameters as name/value pairs
    • The scheduling should be done according to your business needs (hourly, Mon-Fri between 8:00 and 18:00)


Example

You need to pick up exchange rates without deleting them from the source folder, or you do not want to send a request message from SAP ERP to receive the latest updates (e.g. master data from a CMS). Set up the MessageTrigger Job in NWA and define the scheduling according to your needs.

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

 

AE-AE / ICO-ICO Connectivity

ICO_ICO_Challenge

Challenge

You want to set up a communication across two Adapter Engines (AEs), because you have each AE in a different network zone. For Dual-Stack Systems you can choose different adapter engines for the sender and receiver channels, but an ICO (Integrated Configuration) is always running on one AE.

Solution

You have to set up two ICO´s, one for each AE.

ICO_ICO_Scenario

  • For the AE-AE connectivity you use the SOAP adapter in XI 3.0 mode to ensure reliable messaging and keep all the meta data of the SOAP message (e.g. DynamicConfiguration as FileName, Sender IP-Address, etc.).
  • For the second ICO do not forget to set the Virtual Receiver in the ICO header data (you can remove the receiver when sending the message from the first ICO via Header Mapping, but we recommend keeping it for transparency reasons).
  • Use Channel Templates to facilitate the handling (C2D = central to decentral)
    • SOAP_RCV_C2D / SOAP_SND_C2D / SOAP_RCV_D2C / SOAP_SND_D2C

There are two approaches possible that make sense from an interface point of view:

  • Out->In=>In->In
    • The first ICO is performing the mapping (Out->In) and
    • the second ICO is using a Dummy Sender Interface as an Inbound Message
  • Out->Out=>Out->In
    • The first ICO is only doing the routing keeping the Outbound Interface as the Receiver Message and
    • the second ICO is performing the mapping (Out->In)
  • The recommendation is to perform the mapping on the Central Adapter Engine, especially if you are using Lookups, then you definitely need both approaches

Example

Scenario 1:

ICO_ICO_OIII

This is a Out->In->In->In case from Central to Decentral Adapter Engine. The mapping takes place in the first ICO.

The interfaces must exactly match (outgoing message of ICO 1 and incoming message of ICO 2). Same applies for Sender and Receiver. The SOAP Sender channel of ICO 2 simply compares the SOAP header data and matches them.

ICO´s:

ICO_1

ICO_2


Scenario 2:

ICO_ICO_OOOI

This is a Out->Out->Out->In case from Central to Decentral Adapter Engine. The mapping takes place in the second ICO.

ICO´s:

ICO_1

ICO_2_O

The setup works in the same way for Decentral => Central Communication (e.g. for incoming EDI messages).

 

Monitoring

In the Message Monitor of the Adapter Engines you will see:

Central Adapter Engine

  • Sender:  SAP_ERP_P    PurchaseOrder_Out (urn:test.com.pi)
  • Receiver: Whitepaper:EDI    EDI_Order_In (urn:test.com.edi)

Decentral Adapter Engine

  • Sender:  SAP_ERP_P   EDI_Order_In (urn:test.com.edi)
  • Receiver: Whitepaper:EDI    EDI_Order_In (urn:test.com.edi)

J2SE Adapter Engine – Setup/Installation

How to use the J2SE Adapter Engine:
The J2SE AE aka “Adapter Engine (Java SE)” is still supported and being maintained by SAP. You can use it if you need a light-weight middleware component on any system close to database, JMS queue, WebService or NFS filesystem.
Mainly it is used to solve the UNIX-Windows NFS dilemma (you want to access a network drive but your PI/PO installation is in UNIX).
Another network/security use case is to install it into the DMZ and use the J2SE AE as a reverse proxy (application gateway) for inbound communication from the internet.

Here you go:

  1. Get J2SE software from SAP (Service Marketplace Alias /swdc -> Support Packages and Patches-> Browse -> SAP NetWeaver and complementary products -> SAP NetWeaver -> SAP NETWEAVER 7.4 -> Entry by Component -> PI Adapter Engine (Java SE) => Downoad XI CONNECTIVITY SE 7.40
  2. Download JRE (e.g. from http://www.oracle.com/technetwork/java/index.html according to the required version) – Java 7 works fine
  3. Install JRE and extract AE archive into file system (only archive com.sap.xi.techadapters.sda is needed)
  4. Copy file servlet.jar (can be downloaded e.g. from http://www.java2s.com/Code/Jar/s/Downloadservletjar.htm) into extracted folder tech_adapter
  5. Install Service under Windows/Unix (use admin rights “run as administrator” when executing the script)
  6. Start the Admin UI from Browser with default port 8200 and user sap password init
  7. Configure the channels you need and communicate via HTTP(S) to your PI/PO integration server

Btw: This approach basically exists since XI 2.0 and is still valid for PI/PO 7.5! See the official documentation: SAP Help.