Skip to Content

This is the second part of my blog series on SOA. In the SOA for Dummies, we have seen what SOA is and how SAP helps customers realize the SOA dream.  In this part, we would look at service provisioning and steps to implement a custom service using SAP Composition environment.

 

SAP delivers enterprise services through Enhancement packages. Each EhP would bring customers, a new set of enterprise services. At certain point of time a particular service could be in development phase. There can also be occasions where some services cannot be or will not be delivered by SAP. Services which are unique to customers and services that are specific to a scenario with zero or no reusability do not add real value in ESOA sense. Hence they might not be delivered by SAP.

 

In such cases, it would be wise to look out for equivalent services from third party vendors or partners. If this fails too, we can go on and implement a new service with the help of tools provided by SAP. Similarly, when certain services provide limited functionality they can be enhanced using the same steps.

 

An overview on different possibilities of implementing and enhancing custom services is described in this excellent The specified item was not found. .Our focus is limited to implementing custom enterprises using Java. It has to be noted that a similar procedure needs to be followed for ABAP based implementations also. The interfaces might look a bit different but the concepts are similar.

 

Applications implemented using ESOA principles, traditionally follow the lifecycle of analysis and discovery, model and build, compose, deploy and integrate and optimize.

!https://weblogs.sdn.sap.com/weblogs/images/251755308/lifecycle.jpg|height=396|alt=Lifecycle of SOA application|align=absMiddle|width=500|src=https://weblogs.sdn.sap.com/weblogs/images/251755308/lifecycle.jpg|border=0!

 

We would be discussing about  „Model and Build” in this blog.

 

The roadmap for implementing it in a company follows this pattern.

 

  • Define a consumer model, a model of the process and what services we would require.
  • Search for the services and identify missing services
  • Define a provider model , services interfaces from a providers viewpoint
  • Implement the defined service interface

 

 You can find the steps related to our development highlighted below.

!https://weblogs.sdn.sap.com/weblogs/images/251755308/stepsindevelop.jpg|height=298|alt=Steps for implementation|align=absMiddle|width=600|src=https://weblogs.sdn.sap.com/weblogs/images/251755308/stepsindevelop.jpg|border=0

 

In an ideal case, the BPX expert design’s a consumer model to visualize the process. There are various models available in ESR which enables the BPX expert to build models based on their POV.Process model definition is followed by defining the required services. Once the required services are defined, discovery of available services is done with the help of ES workplace in SDN. The missing services are listed down. The service interface definitions and operations for each of these services is decided and built in enterprise service repository. These interfaces can then be read in ABAP or Java. A proxy can be generated for this service interface followed by a business logic implementation.

 

Business Requirement and Consumer Model

 

For sake of clarity, we can assume a simple process of bidding for a project. To arrive at a competitive bid, we are estimating the person days required for the project and sending our bid based on that value. It’s assumed, estimation of person days is not available in standard enterprise services. We are going ahead and creating a java based service for this purpose.

!https://weblogs.sdn.sap.com/weblogs/images/251755308/process.jpg|height=393|alt=Process|align=absMiddle|width=400|src=https://weblogs.sdn.sap.com/weblogs/images/251755308/process.jpg|border=0!

Consumer Model

 

We can model a process component in ESR for the process flow described above. The details of steps involved in modeling these model components are out of scope of this script. Please refer to this SDN Article for more details.

 

A typical process component in a process component model looks like this. Each process component has its service interfaces and each service interface contains operations.

!https://weblogs.sdn.sap.com/weblogs/images/251755308/processcomponentmodel.jpg|height=394|alt=Process Comp Model|align=absMiddle|width=450|src=https://weblogs.sdn.sap.com/weblogs/images/251755308/processcomponentmodel.jpg|border=0!

 

We can now proceed with the technical details of building service interfaces and implementing them.

 

 

Provider Model</p><p> </p><p>Provider modeling involves service interface definitions with its operations and message types. </p><p> </p><p>A Service Interface represents the metadata description of the messages and operations to be used at runtime.  </p><p> </p><p>Service interface are modeled in ES builder of ESR. ES builder is accessed with the URL,</p><p>http://<web as hostname>:<webas port>/rep</p><p> </p><p>Select a software component and choose a folder and create a service interface for  Persondays calculation.</p><p align=”center”>!https://weblogs.sdn.sap.com/weblogs/images/251755308/folder.jpg|height=169|alt=Folder|align=absMiddle|width=365|src=https://weblogs.sdn.sap.com/weblogs/images/251755308/folder.jpg|border=0!</p><p> </p><p>Enter the service interface details. Create an operation, “CalculatePersonDays”. Operations represent the specific actions that can be performed by the service at runtime. Each service interfaces can contain more than one operation. Choose request and response message types for “CalculatePersonDays”.</p><p> </p><p>We assume the required message types are already created and use them here. In real life, careful investigation has to be done before creating our message types and data types. It is a good practice to try to re-use the standard GDTs provided by SAP for this purpose.</p><p align=”center”> !https://weblogs.sdn.sap.com/weblogs/images/251755308/servicedef.jpg|height=267|alt=Service Definition|align=absMiddle|width=600|src=https://weblogs.sdn.sap.com/weblogs/images/251755308/servicedef.jpg|border=0!</p><p> </p><p><br />After choosing the message types, save and activate all changes. The service interface can now be accessed for proxy generation.</p><p>Implementing enterprise service

 

  1. Open your CE developer studio and choose Windows->Preferences->Web Services -> Enterprise Service Browser. Enter the SID, hostname and port of the ESR server.
  2. Create a new DC of type EJB Module.
  3. Login to Enterprise service browser and search for the service interface to implement.

 

Select the service interface and generate java bean skeleton. This would generate the proxy classes in EJB module.

 

!https://weblogs.sdn.sap.com/weblogs/images/251755308/proxygen.jpg|height=200|alt=Proxy Generation|align=absMiddle|width=495|src=https://weblogs.sdn.sap.com/weblogs/images/251755308/proxygen.jpg|border=0

 

While generating the service interface, make sure that the option „Develop service”  is selected.

 

!https://weblogs.sdn.sap.com/weblogs/images/251755308/developservice.jpg|height=220|alt=Develop Service|align=absMiddle|width=573|src=https://weblogs.sdn.sap.com/weblogs/images/251755308/developservice.jpg|border=0!

 

      4. Implement service and deploy the project.

 

A sample implementation

Sample Implementation

 

       5.  Once the service is deployed, an endpoint has to be defined for consumption.

End points are defined in NetWeaver Administrator. Logon to the NetWeaver administrator and navigate to

 

SOA Management -> Business Administration -> Web Services Administration

and define the endpoint.

 

!https://weblogs.sdn.sap.com/weblogs/images/251755308/destination.jpg|height=398|alt=Destination |align=absMiddle|width=472|src=https://weblogs.sdn.sap.com/weblogs/images/251755308/destination.jpg|border=0

 

End point definition makes the service viable for use. The final step is to publish in a registry.

 

      6. Service Registry is UDDI V3 compliant registry which is available precisely for these purposes. To publish the service in registry, create a publication restriction in NetWeaver Administrator.

Navigate to SOA Management -> Business Administration -> Publication Restrictions and create a publication restriction by choosing the EAR file containing the implementation. The service will now be published into the service registry.

 

      7. To test the service, login to WSNavigator, search for service „PersonDaysIn” and test.

 

!https://weblogs.sdn.sap.com/weblogs/images/251755308/test.jpg|height=167|alt=Testing the service|align=absMiddle|width=600|src=https://weblogs.sdn.sap.com/weblogs/images/251755308/test.jpg|border=0

 

Thus a complete service is implemented and published in service registry for further composition and orchestration.

To report this post you need to login first.

6 Comments

You must be Logged on to comment or reply to a post.

  1. Alex Lau
    This blog is a nice overview of the development of custom ES. However, it is too brief for creating a real ES. It would be nice to point out relevant reference.
    (0) 
      1. Earnest Thomas
        Hi Bharathwaj,

        Thanks a lot for this blog and it’s superb down to earth presentation of SOA. Helped a newbie like me to grasp things pretty fast.

        Had a query…where can I find some helpful stuff on the other parts of the lifecyle?
        – Compose and Orchestrate
        – Integrate and Deploy
        – Manage and Optimize
        – Analyze and Discover

        I am looking on the above primarily to understand the concepts involved and to understand the way things are done in a practical environment.

        Any help would be deeply appreciated.

        (0) 
  2. Amol Deshpande
    i had gone thru all ur blog related with SOA..its very good n easy to understand

    please explore ABAP n SOA relation.. i am keen to know if any related examples.

    Thanks,

    (0) 

Leave a Reply