As I mentioned in Does Enterprise Development Have to be Painful, Part One, I've been exploring the world of enterprise software development with SAP NetWeaver Composition Environment (after this, SAP NetWeaver CE), as part of a challenge from SAP Labs to see how much I could accomplish with minimal training and direction (though with the offer of assistance from one or two of their consultants if I managed to get myself completely stuck).
I decided that my best approach would be to build a simple, self-contained application with their system, writing as little code as possible and using as many of their tools as I could. I settled for a tiny task tracking application, in which a task has a due date, a description, and an associated category. The entire application consists of two models, their business logic, and a user interface. SAP NetWeaver CE provides plenty of tools to build, manage, and deploy these types of business objects and their relationships, so I thought this would be a good basic experiment. This is a standard CRUD-style application, where the code needs to Create, Read, Update, and possibly Delete data.
Is it too basic? Perhaps; if this were the only type of application I ever built, SAP's tools are definitely overkill. I don't need clustering or monitoring or failsafe deployment and rollback to keep track of what I need to do in a day. However, it was the minimal application I could imagine that exercised most of the parts of the system that a real application would actually use. In building and deploying the task tracker, I performed the work that a real team would perform when building and deploying a much larger application. I just didn't have to invest several months to design and build such an application. My design took me a day, and I figured that building the application myself should take a couple of ideal calendar days.
SAP NetWeaver CE has two main parts. The first is a server component that represents the large database, cluster, services registry, user management, and central configuration of an enterprise-wide installation. For the most part, I ignored it except to make sure it was running and to perform a few configurations. The second part of the system is an IDE built on Eclipse. If you're at home in Eclipse or another IDE and don't mind performing some visual modeling instead of writing heaps of code yourself, you will find the IDE very comfortable.
This modeling was simple. Although I like opening a text editor and writing some declarative code to tell an object-relational mapper the structure of my database (or to make that tool generate my schema for me), the model design tool in the IDE was easy to use. I didn't have to think about creating tables or choosing column types or optimizing data for JOIN operations. If the abstraction holds through my application's lifecycle, I won't have to worry about versioning or migrating data between schema changes.
Declaring my Task and Category models was as easy as creating new business objects and selecting from menus of available attribute types. Although mousing around was probably slower than typing the corresponding short declarations in a text editor, there's enough metadata slinging happening behind the scenes that I didn't perceive any mild inefficiencies in the UI; it was doing enough of the other work for me.
This was the easy part of the process, and with the help of one of the built-in tutorials, I had two models built and associated very quickly.
The word model should make you think that these models contain business logic. They do. However, this is where I first ran into trouble. Models have operations -- business logic -- and the IDE gives you an easy way to declare them. For example, I wanted an operation which returned a list of all open tasks and another operation that returned a list of all tasks for a given date. You can create an operation which filters the entire collection of model items on a particular attribute, but apart from creating some metadata (I assume hidden somewhere) and adding a method stub to the generated Java Bean for your model, nothing else happens. You have to write code that uses the appropriate SAP Java APIs to perform this filtering. The help system has some information on how to write query filters, though it is unclear. (Likewise, the tutorial example provided is missing code and writes to a deprecated API.)
As with the basic model structure, you model operations in the IDE, selecting the input and output types (both provided by the Composite Application Framework and modeled explicitly on your own) as well as any exceptions that the operation might throw. The IDE generates methods on your model beans for you, but only signatures and empty implementations that return
null. It's up to you to implement the rest of the code. One of my initial experiments was to create an operation that returned a collection of all of the open tasks by filtering out all tasks with an open status. I originally modeled it believing that taking the status type as an input parameter was the right approach, but it appears that creating a non-parameterized filter in the body of the method is correct.
I set aside the notion of finding the most correct and purest design in favor of getting the back-end model to communicate with a front-end UI, specifically through the use of Visual Composer. Visual Composer is a UI-builder with intelligent widgets configurable almost entirely through a drag-and-drop interface built with SVG and other web technologies. There's no code required. Visual Composer can consume web services if you have them deployed properly, which means you need to produce a valid WSDL file and publish it somewhere that Visual Composer can access it.
I had trouble with this step. There are several different ways to expose business models as web services. Their context menus available from the project navigator give you the option of exposing them directly. You can also model services with their own operations apart from your business models. I assumed that providing an application service would be the proper approach; however, all of the tutorials and documentation I saw described the very configuration of application services and again gave very little information about what the body of the generated methods should contain. I'm comfortable writing business logic, but I didn't find a good reference to the types of operations most often found within these methods, nor the preferred and current APIs provided for performing this logic.
Although the generated business models all have CRUD methods provided to create, read, update, and delete business model instances, the generated application service has no operations by default. I didn't see an easy way to link in the operations of the business models. Presumably it is possible to expose those operations directly, or to wrap them in the application service. I can understand the organizational principle of modeling business objects and providing different API bundles for different types of applications, but the enforced striation seemed excessive for my very simple purposes. (In larger projects, it's likely very important.)
I decided to expose the Task models operations directly as a web service. Configuring and registering this web service with my SAP server for Visual Composer's consumption was the most complex part of this process. My contact, Armand, walked me through testing the web service from the IDE (which launches a web service browser), configuring the web service both inside the IDE and deploying the service to the SAP NetWeaver server, and creating a destination for the web service in the SAP NetWeaver Administrator. At that point, we restarted Visual Composer, and I was able to see my web service as a data component within Visual Composer. Since that point, I've learned that you can right-click on the services search widget within Visual Composer to refresh the services cache without restarting the system.
After all of that, building a UI with Visual Composer was simple. Visual Composer presents a few menus of widgets, including buttons, table lists, and input boxes. Because WSDL includes remote calls and argument types, you can easily connect a UI widget with the proper parameters such that input and output displays properly. You can consume several web services in a single form; one view of the UI shows logical relationships and data flow between widgets and services and the other is a layout view, which allows you to rearrange the actual view of the UI.
With everything working together, I had finally achieved my write-test-debug cycle. Even though my actual code is minimal, my web services are small, and my operations are few, the cycle is not fast. My under-powered laptop running the SAP server, the IDE, and Visual Composer takes several minutes to generate, build, and deploy a new version of my web service to the J2EE server, and Visual Composer takes a few minutes to start. The effective cycle of experimentation is by no means instantaneous or cheap. If you're interested in performing similar experiments, I cannot recommend more highly browsing through an existing non-trivial application to get a feel for how components connect. The better your understanding of the pieces and their relationships, the less time you'll have to spend backtracking and redeploying to correct your mistakes. Experimenting on your own from scratch is very time-consuming. I also recommend a high-powered development machine -- or better yet, a separate machine for the server and another for the development station.
Having built a trivial application, I see the power of this system. It took me much more than an afternoon to put things together correctly the first time, but reproducing my results even on a new project will be easier. Except for the initial system configuration and deploying the web service, the only difficult or time-consuming steps of the process were those for which the available documentation is skimpy or absent.
My next task is to bundle the application for deployment and distribution. That's the subject of my next article.
chromatic manages Onyx Neon Press, an independent publisher.
Return to O'Reilly Network.
Copyright © 2009 O'Reilly Media, Inc.