Developing both in the (Java-based) SAP NetWeaver Composition Environment and NetWeaver ABAP, one notices that developing in ABAP is very code-heavy, while often the same tasks can be accomplished in a purely model-driven way in the Composition Environment.
Why is there more MDD in Composition Environment than in ABAP?
So working in Composition Environment, you can get very far just using graphical editors in the Eclipse IDE, whereas in ABAP you need good programming skills. Among the reasons for this are:
- With tools such as EMF available in Eclipse, it’s easier to build the graphical editors, code generators, and merge capabilities for custom enhancements to the generated code in Composition Environment than in ABAP.
- Where there are special editors in ABAP, they are often less graphical than in Composition Environment because that is harder to build in SAPGui (for an example, compare the navigation editors in Web Dynpro ABAP and Java).
- Composition Environment follows (mostly) a pervasive approach, meaning that the run-times and design-times of the Composition Tools “know each other”, allowing the user to model applications that use several Composition Tools without ever having to write glue code in order to connect two tools.
Practical benefits of model-driven development
The pros and contras of model-driven development have been in discussion for years. The benefits I would value most highly are the following:
- The model content developed within such a framework exists within the boundaries of a well-defined meta-model which defines consistency requirements, resulting in some guaranteed degree of internal consistency that you don’t get when you’re free to code anything. This includes formal consistency (e.g. avoiding circular references) as well as developing consistently within a domain meta-model.
- Graphical editors are intuitive and easy to use, improving productivity. (Also, collaboration benefits from developers understanding the work of their colleagues more easily thanks to an intuitive graphical representation.) However, opinions on this point vary strongly.
- Current model-driven development tools usually offer the flexibility to “break out” with your own coding and replace the framework’s generated code wherever it doesn’t fit your purposes.
- Also, they offer good support for adding and managing your own code while separating it from generated code (to avoid manually added code from being deleted when the generated code is refreshed) and have achieved good robustness in comparison to earlier attempts.
- Model content is typically represented in XML, offering a higher degree of abstraction from the underlying technology than native code.
- This allows for some degrees of platform independence, or portability across releases, tools, or even development platforms. By adding new generators, you can generate and deploy code from the same model into different development and runtime platforms. (For example, web service and data type definitions modelled in SAP’s NetWeaver Enterprise Service Repository (ESR) can be deployed into Java as well as into ABAP.)
- If business content is available in a repository at a model level (for example, descriptions of business objects residing in the Business Object Repository), it can be easily accessed for many purposes such as generating integration scenarios, change logs, event coupling, workflows, persistency, authorizations, business rules, semantic representations, and so on. This is, in my opinion, the most eminent advantage of keeping model content in addition to its concrete implementation.
ABAP in Eclipse
I’ve mentioned earlier that the Eclipse IDE makes it easier than the SAPGui-based ABAP IDE to develop graphical model editors and code generators. However, “ABAP in Eclipse” is a topic that has been in the air for years.
A few years ago, a prototype of an Eclipse-based ABAP IDE was demoed at SAP TechEd DemoJam, creating a lot excitement. There is also a commercial product available.
Ever since then, the rumours about SAP actually offering a real and official Eclipse-based ABAP IDE haven’t stopped. Lately, SAP is no longer making a secret out of it: SAP TechEd 2010 even had a session with the following description:
ABAP in Eclipse: A Lab Preview – This session is about the new environment for ABAP development in Eclipse. ABAP in Eclipse offers state-of-the-art ABAP development tools on top of the Eclipse platform in order to increase developers' productivity in today's increasingly complex development environments.
Outlook
When ABAP in Eclipse becomes a reality, I expect that at first they will cover the basics and try to achieve to good adoption by focusing on one or two killer applications. In the long run, I hope for
- more model-driven development in ABAP
- more platform-independent representation of business content, allowing to share content between NetWeaver ABAP, Java, and non-SAP platforms
- an Eclipse-based BOL editor (with the potential to evolve into a cross-platform Business Object Model editor, unifying existing attempts such as the BOR, BOL, Workflow Classes, and CAF)
- generally better support for cross-platform development (e.g. cross-platform BPM processes and BPM – Business Workflow integration)
