Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
vikas2
Active Participant

PI 7.31 introduces a Java only version of PI. This obviously is much more efficient for message processing. However, many existing XI/PI customers have built processing logic on ABAP stack.  In this blog, we’ll look at the steps that can be carried out to create similar functionality on Java stack. I hope the information will be useful and I welcome any suggestions/comments.

     I’ll take a sample use case – dynamic receiver determination based on custom table entries. ( i.e. based on file name, route the      message to different receivers ). For our discussion, the table will be very simple - it has three columns : id, filename and receiver. Id      is primary key and filename is the field that is compared to pattern match with the message's filename to determine the receiver      business system. The table is too simplistic and data won't be normalized but let's ignore that for now .

Of course, it can be easily implemented using XPath expressions in PI 7.31 but I'm using this as it covers a functionality that was often implemented by clients on ABAP stack and it's a good use case as we can use it to show usage of  persistence.  On ABAP stack, this functionality can be implemented using the following approach.

  • - Create an ABAP class (with interface IF_MAPPING ) for processing logic where lookup on custom table is performed. This ABAP class is used in the operation / interface mapping.
  • - SM30 can be used for table maintenance
  • - SE16 can be used to display table entries.


As shown in the below diagram, a message may arrive / leave at Java stack but the scenario used ABAP development infrastructure. Of course, it was not mandatory but given ABAP skill set being more widespread in SAP landscapes we had the below situation in many cases.

 

So in a file to file transfer, the FTP adapters (on Java stack ) will receiver / send files and an ABAP map is used to perform lookup to find the receiver.

Option from PI7.31 onwards:

 

The following approach could be taken to create similar functionality on Java stack:


  • Create tables in Java dictionary.

  • Since SAPUI5 is supported by SAP AS Java and is the recommended UI by SAP, it can be used to build display and maintenance screens.

  • - For server side processing ,we can use servlets to handle requests from SAPUI5 client. We'll need two servlets - one to display data entries already in database and a second one to create new entries.

  • - Receiver determination class is on Java stack where we can use Lookup API in a java mapping program. This is a normal Java map and can be built using DatabBase Accessor. I won't cover in this blog but the github link for this project has the code which can be referred.

To keep the model simple, we can perform database operation in the servlet itself via JPA and not really go via EJBs. EJBs can be used for more complicated scenarios.

Additional Libraries Required:

  • As it's much more easier to use JSON with any Javascript library including SAPUI5, we’ll use Google GSON libraries to convert server side response to a JSON message.

     Hence, our development objects will look somewhat like this.

We'll use SAP Java Development Components ( DCs ) to leverage benefits of NetWeaver Development infrastructure for lifecycle management.

Some customers may still want to maintain the database on ABAP stack ( e.g. in their ECC system / SOLMAN etc .)  and have it replicated to Java stack. In these cases, the messages can be sent to Java AS over HTTP via a RFC destination by tying it in with changes over ABAP tables. In case servlet expects/ returns JSON messages, we can use the standard ABAP class /SDF/CL_E2E_XI_ALERT_JSON_DOC / use SCN’s code exchange to get the JSON tool in case your ABAP system doesn't have this standard JSON processing class.

In this case, the scenario will look like as below.

Implementation Steps ( our original scenario using SAPUI5):

  1. Google GSON libraries: Create a DC of type external library with Google GSON jar to package the required libraries. This is required as the servlet response will be in JSON format which can be easily interpreted by the client side SAPUI5 JavaScript code.

  • - Create a DC for external library and add the jar file to libraries folder.

Change the access to allow access for both COMPILATION as well as ASSEMBLY.

  • - Ensure that both public parts have jars.

     2. Create a dictionary DC. It’ll have an ID column and FILENAME and RECEIVER columns. Based on FILENAME, we’ll determine the      RECEIVER.

Create dictionary and deploy it to SAP Java Server.


  • - Create an additional TABLE for generating keys. We’ll use this later for primary key generation.

  • - Verify that the table exists on database. You may switch to database development perspective. Create a connection using your dB connection details.

3. Create an EE application of type “Web Module” and perform the following steps:

  • Add JPA support by modifying project facet.


  • - Generate entities from tables. This will generate a class for the database table.

It should already have the below annotation.

As we’ll use key generation from a different table (TMP_KEYGEN) , the below annotations are required.

Update persistence.xml to change the transaction type as Local as we’ll be managing transactions in servlet code while persisting data.

  • In summary:

  • Add SAPUI5 SCAs and put dependency for both the DC as well as the SC.
  • Add SAPUI5 Javascript libraries.
  • Add SAPUI5 Java libraries.
  • Update web.xml to add components required for SAPUI5

  • - We’ll create two servlets: RetrieveData will display existing table entries and UpdateData is used to create entries. Both servlets will need to have the JPA information injected at runtime and hence we need the following annotation / declaration.

RetrieveData servlet will return all values in the database.

  • - UpdateData inserts values to the database table:

write( response, map ) is a helper method has been written to write the JSON response - it's the last 3 lines of the previous servlet.

Nothing too fancy in html file – it calls the main view.


I won't go throught the entire JS code. Essentially it builds the views shown later below. The Javascript code invokes GET method on RetrieveData servlet. Here, we invoke a GET method on RetrieveData servlet and push the result into an array which can later be bound to a table that will be displayed.

And code to trigger POST. We just display an alert message .

Java files structure for the web module:

and files for UI in the web module:

This is how the project DCs look.


Dictionary DC was created and deployed separately as it doesn't have to be part of this EAR.

jsonlib: Has Google GSON libraries for Java processing.

detcvr: It's the webmodule - It has servlet , views as well as JPA generated entity file.

dtrcvear: It is our EAR to deploy the application to SAP AS Java.



This is how the screen turns out to be. We can maintain values :


And entries are dsiplayed using the "Display Routing Values" tab.

To test in PO, create an iFLow with two receivers, one default and the second one will be determined based on Java map which will perform a lookup on the table to get the receiver business system based on filename. Configure Routing with Dynamic Message Router

and process two files: First with an arbitrary name and second one has name starting with IN which was updated in our dB by SAPUI5 application. Based on the table entry, the message is routed to BS_DUMMY_IN business system.

The code for this project can be referred at https://github.com/viksingh/PIDYNAMICRCVDCs .


2 Comments
Labels in this area