I have been doing some work of late with Java proxies on SAP PO .I tried to use product documentation to understand their working. Product documentation is always the best source of information but things are much clearer for me after I've already developed something using a concrete example.
I hope that this post will be useful for anyone trying out SAP PI Java proxies. Here both the sender as well as receiver are Java proxies and it has been implemented on a 7.31 SAP PO system.
Scenario: We’ll use the flight demo model scenario with two Java proxies - interfaces FlightSeatAvailabilityQuery_Out_new for outbound service call and FlightSeatAvailabilityQuery_In_new for inbound service implementation.
Broadly, we’ll have three major objects:
Sender Proxy ( Consumer ) - Being sender, this proxy doesn’t provide any service but is used to make the outbound service call.
Receiver Proxy - It has the actual service implementation .
Servlet ( for testing ) - As the proxy calls are to be in an JEE environment, we’ll create a simple Servlet for testing.
At a high level, the below diagram shows what we’ll end up creating. We’ll need to create a configuration scenario as well but that shouldn’t cause too much grief.
We need to create the below projects in NWDS. The names in italics are our project names.
a) Dynamic Web Project ( JavaProxyWeb ). This will hold consumer proxy (sender objects) and servlet used for testing.
b) EJB Project ( JavaProxy ) : This will hold service implementation on the receiver side.
c) EAR (JavaProxyEAR) - EAR to deploy JEE objects.
So we have the below three projects to start our work..
Consumer Proxy Generation
Let’s generate code on the sending side ( consumer proxy ) . We don’t want to chose a Javabean as there is no actual service implementation. We’re just generating client to call our proxy and hence chose “Generate Client”.
.
In the next screen , check the values of Server/ WebService runtime and verify your Dynamic Web Project and EAR project are chosen.
And we don’t have to WSDL as we’re not really using the end-points for any service all . We’ll be creating a configuration scenario in PI Designer to generate the configuration.
After that, let the wizard go through default values and just press finish.
Inbound Service Generation
For our inbound service implementation, let’s take the corresponding service interface. This time we want to generate a bean and hence chose “Generate JavaBean Skeleton”.
And as we’re not really going to use any client, we can move the slider for client to minimum and just generate the shell for the Web Service.
Our EJB project looks something like this.
And the web project should look similar to this.
Adding Servlet to web project ( for testing )
As we need a servlet for testing, let’s create one in our web project.
Additions to servlet which makes the outbound proxy call object
Add the WebService annotation with the service name and create an instance of the Service.
This is the outbound service call. We need to create an instance of port and as we’re using XI as the message protocol, we need to use methods from XIManagementInterface.
and the actual proxy call to get the result.
We have set the business system programmatically. It’s also possible to not set it here and instead set Party and Sender Service in configuration for Java proxies ( this appears once the project is deployed ) in Port Configuration.
Inbound Service Implementation
For the inbound service implementation, we’ll need to add @XIEnabled annotation and it’ll need @TransportBindingRT as well. Add @XIEnabled and IDE will help with @TransportBindingRT as they’re required together.
Project Deployment
Our EAR has our EJB as well as dynamic web project.Deploy the EAR .
Service verification in NWA
Once the project is successfully deployed, we should be able to find our consumer proxy . This was actually confusing for me. I tried to deploy the generated client without the actual service call in servlet and it never worked for me. Only when I created the servlet making the outbound call I could see the outbound proxy. It’s best to finish outbound proxy and inbound service implementation along with consumer application ( servlet in this case ) and then try to deploy them in one shot.
Below is the screenshot of the port configuration . We can set the party/ business system here if it’s not set programmatically.
Similarly, the inbound service shows up as well in Service Definitions.
Our development is done. Now, we need to create an integration flow with the required sender / receiver interface values.
Sender communication channel uses XI message protocol for a SOAP adapter and HTTP as the transport protocol.
Similarly, create a receiver communication channel of type SOAP, using HTTP as transport protocol and XI as message protocol.
Path prefix for sending proxy messages bia JPR is /MessagingSystem/receive/JPR/XI.
Do a test with the URL going to be used on the receiving side to verify it’s running.
Now, configure the receiver communication channel. Change the authentication mode to “Use logon data to no-SAP system’ and provide
authentication credentials.
Activate the iFLow and we’re ready to test the set up.
Testing
Fire the servlet and it should come up with the below screen
Put your flight and connection details. We aren’t really using the date and hence it’s not in screen.
And if everything goes well, we should get the below screen.
Voila ! Our proxy worked and it has come back with the response.
This matches with our service implementation - we’re just returning 20 free and 200 max business class seats .
The message can be displayed in RWB / PIMON.
The audit log confirms that JPR has successfully delivered the message along with the response message.
The source code is available on https://github.com/viksingh/PIJavaProxy . I've just put the outbound proxy call in the servlet and the inbound service implementation as these are the two files we need to modify. Rest all were left standard including deployment descriptors.
- SAP Managed Tags:
8 Comments
