Does Enterprise Development Have to be Painful, part three

Does Enterprise Development Have to be Painful, part three By chromaticJune 10, 2008 Comments: 2
My previous two articles covered my experiences with installing, configuring, and building a very small application with SAP NetWeaver Composition Environment (see Does Enterprise Development Have to Be Painful, part one and Does Enterprise Development Have to be Painful, part two. This article discusses bundling and deploying that application, as well as my thoughts on the entire process.
Bundling and Deploying Applications with SAP NetWeaver Composition Environment
Given the amount of configuration and the demands I put on the server because of my desire for rapid feedback, I recommend developing applications against a testing server and deploying them to a production server. It's much easier to develop in an ad-hoc fashion—not worrying about user roles and permissions—until you have to deal with real users and real data. This may be truer with my individual experiments, where data loss and security were lesser concerns than were ease of development and rapid experimentation, but separating development from production is a wise practice anyway.
The interesting question was "How do I bundle the work I've done for an SAP administrator to install on the production server?" I ran across a few references to checking my project into a team code repository, the SAP NetWeaver Development Infrastructure (NWDI). It may be a useful possibility when working with other developers, but it was a separate subject than the one under investigation.
Deployment occurs in two phases, mirroring the division between the data model and the user interface.
From the component browser view in the IDE, you can export all of the information for a CAF application to a file. My very minimal task application produced a 1.5 MB SCA file. (There are options to include other components, which is handy if you have an application that relies on models from other components.) I spent half an hour exploring the IDE to find this option, but once you know where it is, it's easy to use. This process takes a while: the IDE must generate and build the application.
Importing the SCA file is simple; it's the opposite process.
There are some caveats. First, I don't know if this includes any data inserted as a result of testing. (I deleted my test data before I could verify this.) Second, you still must configure the deployment of the WSDL files yourself. That is, the steps I took to connect the web service I built in the IDE to Visual Composer are still necessary on the production server. Armand mentioned that using NWDI to manage my development would have simplified this process.
Even when using NWDI, exporting and importing are much easier with Visual Composer; the Model menu has both options featured prominently. All you need to do is save the model you want to export, and then export it. The server will generate a ZIP file for you to save. Take this ZIP file to any other Visual Composer instance (on the production server, for example) and upload it as part of the import process. (Unlike the IDE export, this took me five minutes to discover.)
Again, you have to perform some configuration in the NetWeaver Administrator to connect Visual Composer to the web service (though apparently NWDI simplifies this too).
Unlike the import process in the IDE, importing a UI bundle into Visual Composer doesn't actually deploy the UI for other people to use. Rather, the Deploy icon prominently displayed in the Visual Composer interface does that. If building and deploying are successful, you'll get two links: one to the HTML version of your application and one to the Flex version. My research suggests that these are the public versions of your application suitable for other people to use.
Analysis
What did I learn from this whole process? First, SAP NetWeaver CE is a big system. My sample application was deliberately small, although it included several portions of the entire developer studio. Nonetheless, I explored only a fraction of the possibilities. There are multiple ways to build UIs and to produce and consume other web services, as well as to re-use built-in components and services. I have a much better understanding of the system now, if only that I'm aware of how much I don't know about it.
This understanding reveals flaws in my experiment. The platform does not make rapid iteration and prototyping easy. I'm not saying that SAP NetWeaver CE is a slow platform, or that it can't be agile, but it rewards more upfront design and understanding of what you want to build. This is not an indictment of SAP's tools; I am simply saying that getting the most value out of the Java and web services stack requires more up-front planning than I put into my project. Of course, Visual Composer seems very useful for rapid prototyping of UIs—even (or especially) if you don't connect it to a backend.
A similar argument applies to the size and complexity of applications developed in SAP NetWeaver CE. Although I intentionally kept my task-tracking application very simple so as to be able to develop and deploy a complete system on my own in a few afternoons, most of the power and necessary complexity of the system went unused. I've built similar systems with a couple of hundred lines of Perl, a few CPAN modules, the SQLite database, and an afternoon. The results suited a handful of colocated users, whereas a project built on and deployed to SAP's systems will support many more. Of course, the latter project will likely have more than one developer and more than a week's worth of afternoons devoted to it.
I expected these results. My biggest question was about learnability. Even though my project was small and arguably inappropriate, I had to learn enough about how to use SAP NetWeaver CE to build a real project if I had any hope of succeeding. The ultimate question for me was not "Does the software work?" but "What does it take to learn how to be productive with this software?"
The IDE includes a large amount of supporting documentation—all specific to the current version of the software—which sometimes offers great advantages over browsing the documentation in the wiki, forums, and resource centers of the SAP Developer Network (SDN). However, there are some inconsistencies in the available material. The data modeling section of the documentation contains a great tutorial, but there's little information on how to add custom operations to the generated models. I had sufficient trouble figuring out how to connect my data model web service to Visual Composer that Armand and I spent an afternoon working through the details. Once we'd done that, I had little trouble, but it's unlikely I would have solved the problem on my own.
I did occasionally rely on the SDN, though it's not perfect either. Plenty of material is available there, including some tutorials and training information. Some of it is great, but plenty applies to older versions of the software. (I followed a few dead ends before realizing that searching had landed me in the midst of a tutorial for an older, deprecated technique.)
Although I never posted directly in the SDN forums, I found some great information there, and it's likely that other SDN participants would have led me in the right direction, if I hadn't had Armand and Angel to guide me.
Here's the most important question: "Where would I use SAP NetWeaver CE in the future?"
Assuming I already had SAP deployed and available in my organization, building applications with these tools makes the most sense when the application:
* Can take advantage of existing libraries, models, services, and processes provided by SAP
* Serves multiple users in multiple roles
* Must integrate other services
In particular, I found the business modeling components powerful and easy to use. Visual Composer is effective for building data-driven user interfaces. I used the administration tools only to configure web services to transfer data between my model and my UI, but unified administration, deployment, logging, and governance are also valuable.
SAP NetWeaver CE doesn't remove all of the pain from enterprise software development. I didn't expect it to. It's not perfect, but in its sweet spot and with a little training or experience, it's powerful and flexible, and I'd consider using it for a real, non-toy application. It's not a tool to pull out for an afternoon's worth of work building a small application, but in situations in which I'd spend a couple of months building something larger—and where my list applies—it's a contender.