Objective
While working on SAP PI you must have come across the following objects i.e. Adapter Module, Java Proxy etc. These PI components belong to the java stack and they are based on EJB.
In the Java world, people know what EJB is but for us who are in SAP PI, we are not very familiar with EJB though this is exclusively used. So let us discuss EJB for a while. Before we start with EJB, it is also necessary to discuss the Web Server and the Application Server.
Web Server vs. Application Server
When we were in colleges, many of us have built our own web-site or have seen our class-mates making some. Most of them has downloaded some or the other freely available web server from the net and built their web application on them. Later when we are working as IT professionals and again making web based application for industries i.e. Banking, Manufacturing, Finance etc., we no longer use a Web Server but we use Application Server. Moreover no application server is freely available in the market. You have to buy it by paying thousands and even lacs of rupees.
Why do we need an Application Server?
It is like making your own boat and trying to cross the river. If you get drowned then it is your bad luck. But if you would like to ferry passengers then nobody will sit in your boat unless they feel secured, no matter how attractive and comfortable it looks. Similarly, the business will look for some primary requirement from your application vis-à-vis their business security etc and once they are satisfied then only they will look into it with interest.
What are those primary requirements? There are many, only some are mentioned here i.e. load balancing, transparent fail-over, transactions, clustering, object life cycle, resource pooling, security, caching etc. Obviously, you cannot be master of all. As IT professionals, it is best we concentrate on finding solutions to their complicated business logic i.e. Finance, Sales and Distribution, Human Resource etc and leaving this primary requirement to different category of people, who specializes in them only. There are many companies who are pioneer in giving solutions to these requirements. They are generally known as the vendor companies and their solution is known as the middle-ware services. You can use their solutions in your application so that you are then free to concentrate on core business logic, coding etc.
That is how an application server is born. The primary requirements are bought from the vendor companies and plugged into a web server. All this needs lot of effort and money. That is why the application server is never freely available in the market and you always have to buy it.
Fig-1: Web Server vs Application Server
A web application is client-server architecture and may be of 2-tier or 3-tier architecture. 3-tier architecture consists of the following:
- Presentation layer - The presentation layer contains the components that implement and display the user interface and manage user interaction.
- Business layer - The business layer contains components used to implement the business logic and to define the business entities.
- Data layer - The data layer contains components used to meet the database access requirements of your application.
In 2-tier architecture, the two layers (Presentation and Business layers) are combined into one.
Enterprise Java Beans
As we move on to build more robust application for our customers we use Application Server which enable us to plug-in the required middle-ware services. To make it possible, we develop objects using the EJB framework.
- Enterprise Java Beans (EJB) is a server side component architecture that simplifies the process of building enterprise-class distributed component applications in Java.
- An enterprise bean is a deployable bean and it has to be deployed in a container i.e. Application Server. Each enterprise bean consists of one java class, two interfaces and two descriptor files. Regardless of an enterprise bean’s composition, the clients of the bean deal with a single exposed component interface.
In Java-world, there is a very familiar term - Java Bean. A java bean is a simple java class with get and set methods. It consists of a single java class. A java bean does not need a runtime environment i.e. container. It is not part of the EJB framework.
Enterprise bean is used to build distributed component application in Java. What does distributed means? A distributed application is one whose components does not reside in one application server but get deployed in several application servers i.e. in different address-space (Clustering). But they work in unison and to the user it appears to be a single application.
Where do we use the EJB framework?
Fig-2: EJB in 3-tier architecture
EJB framework replaces the business layer and the data layer. The objects we built using the EJB framework is known as the Enterprise Java Bean. Application Server plus the enterprise Java Bean together enable us to built robust application in Java for our customers and provide them the necessary middleware services. There are three types of enterprise beans - Session, Entity and Message Driven. Functionally they are classified into two i.e. whether they represent
- business logic or
- business data
Type of Enterprise Bean
Fig-3: Type of Enterprise Bean
The Session Bean is further classified into two - Stateful and Stateless. A Stateful session bean is designed to service business processes that span multiple method requests or transactions. A stateless session bean is for business processes that span a single method call.
The Entity Bean is further classified into two – Bean Managed Persistence and Container Managed Persistence. In Bean-Managed Persistence you map the class variables to the database fields and develop the corresponding database access logic within the bean. In Container Managed Persistence, you only map the two fields in the deployment descriptor and it is the container which generates the database access logic using a Data Access Object.
Functionally the Message Driven Bean is similar to session bean but the only difference is that you can call a Message Driven Bean by sending messages to it. You cannot do lookup.
In SAP PI, we use Session Bean mostly to develop objects i.e. Adapter Module, Java Proxy etc. Henceforth, our discussion will remain limited to Session Bean only. Entity Bean and Message Driven Bean will not be covered here.
Detail discussion on an Enterprise Java Bean
When we write a simple Java class, following are the components of the class
- Constructor
- Methods to support business operation
- Methods for internal operation i.e. data access, reading properties file, modularization of code etc; they are never called by the user.
Similarly following are the components of an enterprise bean
- Life-cycle methods i.e. constructor - create, remove
- Methods to support business operation
- Methods for internal operation and container methods. Container methods are never declared but we extend them from parent interface and over-ride them i.e. ejbActivate, ejbPassivate etc. They communicate with the container.
An enterprise bean consists of two interfaces and a class. One interface bears the signature of the life-cycle methods and the other the business methods. The former is known as the Home Interface and the later the Remote Interface. They make the enterprise bean remote-enabled i.e. the user can call the deployed enterprise bean from another address-space.
Fig-4: Remote enabled enterprise bean
Remote vs. Local Interface
All enterprise beans are made remote enabled to support distributed component architecture. But it comes at a cost. Calling a remote enabled bean adds a lot of overhead, consumes resources and makes the system slow.
Whenever we built an application for our customer, the enterprise beans created can be classified into functional modules. A business process may involve multiple enterprise beans. It is found that barring a few, most of the enterprise beans in one module does not need to call an enterprise bean in another module. So if we deploy the enterprise beans module-wise in different container then all of them need not be remote enabled. A new set of interface has come for them - Local interface and LocalHome interface. The former replace the Remote interface and the later the Home interface.
Fig-5: Remote and Local Enterprise Bean
When remote enterprise bean call each other they pass parameter by value while when local enterprise bean call each other they pass parameters by reference. They consume much less resources and they are very fast. But they will only work when both the caller and the called bean are in the same address-space.
Creating an Enterprise Bean
We start by creating the two interfaces and the class. We declare the life-cycle methods and the business methods in the two interfaces and implement the same in the class. For remote enabled, we use Remote and Home interface and if not required then we go for Local and LocalHome interface.
Next, we declare two descriptor files - Deployment Descriptor and Vendor Specific File. We plug-in the necessary middle-ware services for our bean through these two files. The two files are needed as not all middle-ware services can be configured in a similar fashion across the containers. Some are vendor-specific and need vendor-specific way of configuring. EJB specification does not touch them. While the deployment descriptor is portable across the container, the vendor-specific files are not.
Deployment Descriptor | Vendor Specific Files |
It is an XML file | It may be XML, TXT etc |
Portable across containers | Not portable across containers |
Life-cycle Requirements, Transaction, Persistence, Security | Load Balancing, Clustering, Monitoring etc |
Once all the files are ready we bundle them up into a JAR file and deploy them in the container. An ejb-jar file is a compressed file that contains everything needed for deployment.
Calling an EJB
We do not use the ‘new’ operator to make an instance of an Enterprise Bean. A pool of instances is created by the application server when it starts up. They are then ready to cater to request from users. Whenever a request comes from the user, the container maps it to any one of the available instance. The same instance is maintained for subsequent request from the same user if the bean is stateful and is released back to the pool once the user leave. For stateless, the instance is released after every request-response call. When the number of users increases above a threshold limit, the application server may decide to increase the pool or direct the call to another application server.
While calling our enterprise bean how will the user know what are the methods we have declared and how do we call them i.e. arguments. We have to provide them the two interfaces.
If we would like to make our bean remote enabled then we have to generate the stub and skeleton. They are the two java objects which take care of the communication protocol across the network i.e. to establish socket connection etc. They act as proxies between the server and the user. They are generated from the two interfaces – Remote and Home
Following are the list of objects to be deployed at the user and the server end.
User End | Server End |
|
|
|
|
Note – Stub and Skeleton is only applicable to remote enabled bean and not the local bean
An example on Enterprise Bean (Type - Session)
Suppose you are a user and you are doing online transaction on your savings account. These are the operations you are executing.
- login to your bank account using your user-id, password combination
- check your account balance
- transfer amount from your savings account to your credit card account
- logout
The above functionality is implemented in an Enterprise Java Bean. Method 1 and 4 are life-cycle methods. They are called only once during the life-cycle of the bean. Method 2 and 3 are business methods and may be called any number of times.
Fig-6: User-Account Enterprise Bean
As the user session has to be maintained we will go for the Stateful session bean. When the user logs-in, the container engage one instance to the user and it remains committed for the entire session. The user then checks balance and transfer amount to credit card account. When the user log-out, the instance is released back to the pool and is ready to cater to the need of any other user.
Adapter Module
Integration Engine communicates with non SAP System using the adapter’s i.e. FILE, JDBC, SOAP, JMS etc. They belong to the JAVA stack. The adapters convert message from the native protocol to the HTTP-XML protocol and vice-versa.The Adapter Framework is the basis of the Adapter Engine. The Adapter Framework contains two default module chains: one for the sender/inbound direction and the other for the receiver/outbound direction.
Modules are java application developed in EJB. We add them to the relevant location in the default pipe-line i.e. module-chain and they provide us the ability to process messages between the messaging system and the default adapter i.e. the one which connects to the external system. There are standard modules provided by SAP and we can also develop our own custom modules using the SAP provided API. More than one module can be added to the module chain. But the default adapter is always the last in the chain for inbound flow and the first in the chain for outbound flow.
Fig-7: Adding modules to the default module chain
A module is not for persisting data so it is developed as a Stateless Session Bean. If you look at the skeleton code - the bean class extends both the Session Bean interface and Module interface.
public class Module_Name implements SessionBean, Module {
public ModuleData process(ModuleContext moduleContext, ModuleData inputModuleData) throws ModuleException {
// code here
}
}
The Module interface is specific to SAP and communicates with the pipeline to exchange messages. The modules are developed as an EAR file and deployed in the container. The orders in which the modules are called and any configuration parameter needed are defined in the adapter i.e. the module tab of the communication channel.
Java Proxy
Proxies are features provided by SAP to connect the Integration engine to an external application i.e. Java and ABAP. Proxy is generated from the corresponding service interface.
- Outbound interface generates client proxy and
- Inbound interface generates server proxy
Proxy support both synchronous and asynchronous communication. For synchronous communication, the corresponding interface should also be synchronous.
Proxy provides us an easy way to integrate complex interfaces with external system. Proxy takes care of all communication protocol and we as developer only integrate it at the application end.
Fig-8: Proxy Communication
We generate an ABAP Proxy when we integrate PI with SAP System. In the SAP system, the generated code will provide us an EXECUTE method.
- EXECUTE_SYNC – for synchronous interface OR
- EXECUTE_ASYNC – for asynchronous interface
We write ABAP code inside the method for calling BAPI, tables, validation etc.
We generate a java proxy when we integrate PI with a Java System. The generated code provides us with an enterprise bean which we integrate with our application. The enterprise bean will have both the type of interfaces for remote and local access. We use the one best fit for our application, depending upon where our application is deployed.
For operating with Java proxy, a Java Proxy Runtime is needed. The Java proxy runtime comes with a message processing and queuing system and provides security mechanisms. Adapters are not needed. We need to define a Business System within the Technical System – Web As Java. This business system serves as the default sender system for client proxies and as receiver system for server proxies as well. We must not assign more than one business system to the same technical system Web AS Java.
There is a difference in configuration between the client and the server java proxies that we need to do in the PI.
Client Proxy – Here proxy is the initiator of the process and so the proxy needs to know where to send the data. When we create a client proxy, the proxy gets created with the details of the integration engine i.e. IP Address, Port, Sender BS, interface name and namespace. We do not need to pass these details to the proxy. Only if the particulars of the integration engine changes, we have to generate the proxy once again.
When you send message with the client Java proxies, the details are already there in the message. The sender service is automatically set to the business system that you have maintained in the SLD. The interface name and namespace are derived from the message interfaces from which the Java proxies are generated. A sender agreement and sender channel is only necessary for Java proxies if you have special requirements for message security.
Server Proxy - Here PI is the initiator of the process and the PI will never know where you have deployed your proxy. So the following configuration is needed to pass the information about the whereabouts of your proxy to the PI.
- Create a receiver Channel – Type XI Adapter with the details of the Java WAS where the bean is deployed.
- Register the server Java proxy to the proxy server. The mapping between the interface name and the class name of the server Java proxy is done by the proxy server. Type the following in the browser
Rest of the configuration i.e. the pipe-line steps are as it is.
And lastly, my special gratitude to Ed Roman's book on EJB for my knowledge.
