Screencast: Create a Java EE Web service in Java CAPS 6 to connect SAP
Introduction
If you have read my 2 previous blog entries and looked at the screencasts I can guess your reaction.
If you are familiar with Java CAPS 5.1, you probably feel comforted because the 2 scenarios are mostly similar to what we would have with 5.1. You probably think that the NetBeans tooling is much improved compared to Enterprise Designer 5.1. Also, you can see that the underlying application server is SUN Application Server 9 (aka Glassfish) instead of 8.0 we have in Java CAPS 5.1.
Now if you are a developer using NetBeans on daily basis, you are probably less comfortable. You are probably asking why you need to use a repository, OTD and collaborations to do these scenarios. You are probably thinking that there should be a way more aligned with Java EE 5. In fact you will be interested that this is where Java CAPS 6 is going.
Let's examine a simple use case: I want to expose the SAP lookup described in the entry as a web service. Doing it in a pure "5.1 way", I would use eInsight to define a simple request / reply BPEL implementing a WSDL defined web service. I would insert the Java collaboration into this eInsight BPEL and deploy.
Now, with Java CAPS 6 there is another way, almost entirely aligned with Java EE concepts. The reason is that the BAPI/RFC OTD we created is in reality a wrapper around a JCA Adapter. Quite simply, there is a RAR file that contains this JCA Adapter located in this directory:\glassfish\addons\caps\eways.
Having a RAR file is already very close to being able to use it inside a Java EE EJB.
This is exactly what I am going to demonstrate here.
Adapter configuration in Glassfish
This is a one time operation.
install the SAP RAR file in Glassfish
create the connection pool and the JNDI resource
configure the SAP connectivity
Creating the project
You still need to generate the OTD using the Java CAPS Repository. Apart from this step of generating the OTD and importing into a NetBeans project, you can disconnect from the Repository and develop inside a pure Java EE world.
This is the EJB code:
The screencast is here (open in a new window)
Conclusion
The main benefits I can see with this approach are:
If you have read my 2 previous blog entries and looked at the screencasts I can guess your reaction.
If you are familiar with Java CAPS 5.1, you probably feel comforted because the 2 scenarios are mostly similar to what we would have with 5.1. You probably think that the NetBeans tooling is much improved compared to Enterprise Designer 5.1. Also, you can see that the underlying application server is SUN Application Server 9 (aka Glassfish) instead of 8.0 we have in Java CAPS 5.1.
Now if you are a developer using NetBeans on daily basis, you are probably less comfortable. You are probably asking why you need to use a repository, OTD and collaborations to do these scenarios. You are probably thinking that there should be a way more aligned with Java EE 5. In fact you will be interested that this is where Java CAPS 6 is going.
Let's examine a simple use case: I want to expose the SAP lookup described in the entry as a web service. Doing it in a pure "5.1 way", I would use eInsight to define a simple request / reply BPEL implementing a WSDL defined web service. I would insert the Java collaboration into this eInsight BPEL and deploy.
Now, with Java CAPS 6 there is another way, almost entirely aligned with Java EE concepts. The reason is that the BAPI/RFC OTD we created is in reality a wrapper around a JCA Adapter. Quite simply, there is a RAR file that contains this JCA Adapter located in this directory:
Adapter configuration in Glassfish
This is a one time operation.
Creating the project
You still need to generate the OTD using the Java CAPS Repository. Apart from this step of generating the OTD and importing into a NetBeans project, you can disconnect from the Repository and develop inside a pure Java EE world.
The screencast is here (open in a new window)
Conclusion
The main benefits I can see with this approach are:
- use NetBeans version control engines (CVS, Subversion) except for a small part (the OTD)
- use NetBeans testing capabilities
- leverage Java EE environment including the powerful Glassfish web service stack
- leverage developer knowledge of Java EE
- configuration at the application server level, not inside the EAR any more