Skip to Content

After hearing about Summary of Shai’s Keynote at SAP TechEd ’06 Las Vegas TechEds suggesting that everyone one of us should create a Composite Application before the next TechEd, I decided that I too would create my own Composite Application.  It might not be an application that would be used in a productive environment but it would be an application that demonstrated the potential of SAP technology in this area.

This blog and the following will describe my experiences in this endeavor. I will describe the steps that I made during this learning process, the “gotchas” that I learned as well as the lessons learned that I discovered.  My wish is that other SDN members interested in working with this technology will get a jump start and be more productive irregardless of the type of application they wish to create.

The learning process

If you are interested in building a Composite Application, where do you really start? If you look at SDN, there is so much information – irregardless of the topic selected – that you often having trouble finding exactly what you are looking for.  I had heard of CAF (Composite Application Framework) and so I thought this would be a great place to begin.    I saw there was a top-level link for CAF, so I decided to check it out.  I read some of the background materials and decided, “This looks like the right technology to build my composite”.  I looked at the SAP Composite Application Framework – CAF Tutorial Center  and thought “Wow, there is a lot of material here.  But where do I really start?” I wanted to get my hands dirty. I wanted to create…


The first step was to create an environment where I could create my application.

  • Download the Trial Version of the 2004s Web Application Server (WAS) SP 9. After downloading the software (a job in itself, inasmuch as the two files together are over 3,1 GB),  I performed the installation, which was very easy -within 5 hours.  The installation requires very few inputs and is primarily based on default values.  Make sure that the hardware prerequisites are followed.  If you try and develop (using Developer Studio) and run a WAS on the same machine, the machine must have enough RAM to deal with both applications running simultaneously.  I suggest installing the WAS on a  different server, developing locally and then deploying to the server. 
  • Download the DeveloperStudio packaged with the Trial Version of the WAS.

I logged on to my newly installed portal and decided to check-out Guided Procedures.  I started the Guided Procedure (GP) design-time and clicked on the various items to get a feeling for the application itself.   I clicked on “callable action” and got an exception that referenced some XML file deep within the WAS.  I said to myself: “This is a great start. If the basic technical building blocks don’t work, how I create my app?” So I turned to all-knowing SDN “Developing Composites” forum and posted my question.  Within a few hours, I received my answer.  Download the entire “” file from the SAP Marketplace and redeploy it via SDM

After following instructions, I tried the GP design time again and lo and behold – the exception was gone.   

GOTCHA: I had looked at a few of the CAF tutorials about CAF and I knew that were a variety of callable objects available.  I looked at my callable objects, I only saw a few items.  After once again posting in the SDN “Composite Application” Forum, I discovered that the the visibility of callable objects is role-dependent.  If you want to experiment with GP then give yourself all Design-time roles described in this Setting up Roles for CAF, GP and Visual Composer.  This is of course a prerequisite that is described in the documentation of most GP tutorials but I never knew its importance.   If you would like to see or change these settings (role – callable object), go to the GP Administration and select “Manage Permissions”.   

After a successful installation, you have environment where you can start to experiment with CAF.

First Mini Application

I now had a working environment and I was ready to create my first application.  I wanted to do something where I would do some coding. I had seen all the famous Composite Application slide with the three layers (Composite Process, User Interface and Business Objects – Services) I thought what about developing in CAF-Core.  I found Austin Chinn’s excellent ESOA Chronicles Part I: Consuming SAP Enterprise Services using Visual Composer and the Composite Application Framework and article “How to Consume an SAP Enterprise Service using Visual Composer and the Composite Application Framework” and decided “This is perfect. Let’s get to work. But let’s make things a little bit more difficult. Let’s use an entity service that is modelled on local persistency instead of an enterprise service.”  Then I started modelling. I didn’t know exactly what I was doing but I thought I could still struggle through it.  I saw that there were three types of services: Entity Services, Application Services and External Services. I really didn’t know what Application Services were – I thought they were similar in some way to Entity Services.

I followed Austin’s instructions and I skipped the parts that referred to the enterprise service.   During this development work, I discovered a few tips / findings that I would like to pass on you.

  • When defining Entities, always use a Capital letter as the first letter of the Entity name.  This is important when the code is generated.
  • After working in various Java projects that dealt with database access, I started to look for the screen where I could set the JDBC settings to store my data from the entity with local persistence.  I looked and never found anything.  The reason being that the data is stored in the WAS database.  Thus, many common database-related issues / problems are hidden from the developer. Of course, you can influence some of these factors by using the Dictionary perspective. The question is do you really want to? During the deployment process, take a look at the database logs and you will see all the SQL-related actions that have been performed. Of course, if you have existing databases that you would like to use, you must use other options (web-services, etc.) to access this data via CAF.  I may discuss the architectural issues of combining application-specific data in the application server database in another blog. 
  • When attempting to deploy remotely, you need the correct message server name and port.  The server name is pretty obvious but the port is often more difficult. For the trial version WAS, the correct port is usually 3900.
  • If you don’t have a custom logger,  then the logs from generated CAF Core code end up in the “applications[#].log,

I then proceeded to make my local persistency entities into web-services.  This is relatively easy and described in a variety of tutorials and SAP help pages.  I will skip a few steps to illustrate an important lesson I learned.  I followed the steps described by Austin’s article and pretty soon I had an Entity service that was available as a web-service.  But I noticed that there were a few problems. For example, there was a restriction regarding which operations could be created in the Entity Service in the DeveloperStudio. I could add new FindBy operations but that was it.  Furthermore, when I accessed the web service from Visual Composer, its signature wasn’t very user friendly.  Everything worked but the results weren’t really satisfactory.

At this point, I realized that I was missing something.  I started reading various CAF tutorials looking for some clue concerning the missing piece in the puzzle. At some point, I took a walk in the fresh air to get a few new ideas. I let all these different tutorials sort of swim by mind’s eye. Then I realized that the Application Services were really the key to the puzzle.

I had always assumed that CAF-Core was sort of magical framework that would solve all my problems. What I now realized was that CAF-Core gives you tools to help alleviate many of the common problems (dealing with EJBs, Naming, logging, etc) but you as developer still have to code the business logic as Application Services. In this way, Application Services are really the aspect of CAF-Core that exemplifies the basic principles of Enterprise Service Oriented Architectures (E-SOA).  The use of Application Services allows you to combine various other services (whether external or local persistence-based) and add a business value and then provide end users a “new and improved” service.  It usually doesn’t make any sense wrapping an External Service in an Application Service without making some change to the service itself.  The direct use of a web-service in another application may indicate SOA but not E-SOA (unless of course the web-service in questions wraps another web-service and adds its own business value….)

If you look at the code generated by CAF Core in an Application Service, this focus on adding E-SOA value is demonstrated. To generate the correct code in this demonstration, first include an Entity service as a dependent to an Application Service.

Next add an operation to the service that uses this entity service.

If you look at the generated code (See below), you will see that CAF Core has assisted you in various ways: 1) it has created a signature for the method and filled it with a skeleton that now must be filled with your business logic, 2)there is another generated method (getCompanyService that enables you to access your entity service. I haven’t included the whole method but you can look at it in your own generated code.

public createCompany(java.lang.String arg0)  {   // logging   java.lang.String CAF_user = sessionContext.getCallerPrincipal().getName();         java.lang.String CAF_methodHeader = InternalCompanyBean.JARM_REQUEST + ":" + "createCompany(java.lang.String)";             Object[] CAF_parameters = new Object[] {arg0};,         InternalCompanyBean.JARM_REQUEST, CAF_methodHeader,      InternalCompanyBean.location, CAF_parameters); retValue;   try {     //@@custom code start - createCompany(java.lang.String)     retValue = null;     //@@custom code end - createCompany(java.lang.String)     return retValue;   } finally {,       InternalCompanyBean.JARM_REQUEST, CAF_methodHeader,     InternalCompanyBean.location, CAF_parameters);   } }   private CompanyServiceLocal getCompanyService() throws {   java.lang.String method = InternalCompanyBean.JARM_REQUEST + ":" + "getCompanyService()";   java.lang.String jndiName = "localejbs/"; java.lang.String user = sessionContext.getCallerPrincipal().getName(); .........  

To access your Entity Service, you can use the generated code and then add your custom business logic.

//@@custom code start - createCompany(java.lang.String) retValue = null;   try {       CompanyServiceLocal companyService = getCompanyService();     retValue = companyService.create();     retValue.setName(arg0);    .........         } catch ( se) {    , location,    se);     }   //@@custom code end - createCompany(java.lang.String) return retValue;

Of course, once you understand this basic architectural construct, then you can get down to work writing the code that really matters and letting CAF Core do its job of creating a solid technological foundation for your application.   

There are a variety of tools (Java-based and otherwise) that assist developers in creating E-SOA applications. What sets CAF apart is its close interdependence with the WAS that not only alleviates many of the problems associated with developing E-SOA applications but also alleviates many of problems associated with the development of such applications for the WAS.

In my next blog, I will discuss my experience with Guided Procedures.

To report this post you need to login first.


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

Leave a Reply