VC and IPC are very generic configuration engines which are suited to many SAP customers. Product models are implemented in generic languages for dependencies with the use of tools like PMEVC and various different transactions each of which allows to maintain a certain object type.
However, usually an SAP customer has its own specific way of using VC and IPC. Special coding patterns are used to achieve desired functionality, there may be restrictions of using some configurator features, and there might be additional functionality added to the configurator. Furthermore, an SAP customer uses its own specific way of specifying product models - which typically happens outside of the modeling environment.
There are no integrated tools for specifying product models. Furthermore, a systematic way of obtaining the implementation of the product model in VC from its specification is missing. For the implementation of product models, generic (and sometimes ancient) tools have to be used.
As product modeling has several common aspects with programming, it helps to look for approaches to these problems in the software-development area. In Model-Driven Software Development domain-specific languages are used to create models which express application structure and behaviour in a concise and domain-specific way. Subsequently, these models are transformed into executable code using model transformations.
We propose to create your own domain-specific language to specify your product models. By using powerful modern open-source frameworks like Eclipse, Xtext, and Xtend2 it is now possible to develop an integrated-development environment for your domain-specific language - your product-modeling environment - with reasonable effort. With the open-source project VClipse as well as with the solution-modeling environment from SAP now two backend systems for the interaction with an SAP system exist which drastically simplify the task of implementing model transformations from your own domain-specific language to a product model in VC or IPC.
We will present as an example for this approach the solution built in a customer project at Nokia Siemens Networks and also give a demonstration.
We examine various aspects of the architecture of a product-modeling environment tailored to your needs. Finally, we discuss whether it is worth the effort to build your own product-modeling environment and point out the preconditions for this approach and describe its benefits.
10. Interface to SAP ECC (ALE, RFC)
● RFC interface
− Create, Read, Update, Delete
− Extract recursively: model extraction
● ALE interface
− Sending models via IDocs (PDR)
● Delta calculation
− Compute and send only changed objects
● „One-click delta deployment“
− Send delta via PDR, automatic processing in SAP
11. Graphical or Textual
Product Modeling?
Deutsch limit:
You can’t have
more than 50
visual primitives
on the screen at
the same time.
12. Focus on Textual Product Models
● Dependencies are written in textual languages
● Teamwork support through mature version
control systems
● Powerful tools exist and can be used for free:
− Difference tools, search, replace, ...
● Enables offline product modeling
● More information is visible on a screen
● Text-based product modeling environments are
easy to create with today's frameworks
14. Why Own Specialized PME?
● Product modeling environments from SAP
have to suit all models of all SAP customers
● Customer-specific product modeling is not
supported
− Naming conventions
− Coding conventions
− Variant functions
− …
● Customer's notions not used
− Not everything is a material, class, or characteristic
15. VClipse is Not (Yet) Your Own PME
● not (yet) customer-specific
● Several layers to extend Vclipse:
− As a user / modeler
− As a (Java) programmer
− As a contributor
16. Extending VClipse – as Modeler
Define your own templates
E.g., template for determining amount of a material
(specific coding convention)
17. Extending VClipse – as Programmer
Write your own plugins / extend VClipse plugins
Specific validation rules
● e.g. naming conventions
Resulting validation in
VCML editor
VcmlJavaValidator.java
18. Extending VClipse – as Programmer
Coding conventions / Framework code
● Classes and dependencies are required by
the „framework“ for different functionalities
● Validation rules should check
− if a certain procedure or dependency
net is present,
then certain classes must be present.
− the order of procedures
− …
● Templates (by a modeler)
− The classification and configuration
profile could be generated by a
template.
19. Extending VClipse – as Programmer
● Specific „intelligent“ templates
Implementation:
20. Specific Support for Variant Functions
● Implement specific validation
● Implement specific code templates
PFunction Z_COPY_DEFAULT_MV (
GEN_CSTIC_1_NAME = 'MVCSTIC1'
GEN_CSTIC_2_NAME = 'MVCSTIC2'
GEN_INSTANCE = 'PARENT'
)
name of multivalued characteristic
one of SELF, PARENT, ROOT
compatible type
22. Extending VClipse – as Contributor
Testing language VCMLT for VCML models
(contributed to VClipse by Winfried Kung)
See talk by
Tim Geisler and Christophe Faure
Track 3, 11:15 – 12:00
23. Conceptual Gap
● SAP VC's concepts
● Implementation
● Standard languages
● Transactions
● VClipse
● Your concepts
● Specification
● Your languages
● Your own
modeling environment
24. Your Own Modeling Language
● Why?
− Tailored to your concepts and needs
− Means for specifying the product model
− Means for communication with the domain expert
− Formal specification language
● Overcome the gap by generating VCML code
28. When to Create Own Language and
Product Modeling Environment?
● Schematic product specifications
● Similarly structured products
● Schematic translation
● Schematic implementation
● Model migration from legacy to SAP
− intermediate language with manipulation
possibilities (refactoring, commented code, …)
● …
29. My Own Product-Modeling Environment
RFC
Editor/IDE
Editor/IDE
my ConfigModeler
VClipse
myCML
VCML
my Code Generation
32. Defining your
Modeling-Language Grammar
● using the Xtext grammar language
● from this grammar, the following is derived:
− metamodel (Ecore + Java classes)
− parser
− editor with syntax highlighting, cross references,
content assist, outline, folding, ...
35. Defining your
Target Architecture
Clear: SAP Variant Configuration
Open aspects:
− Naming conventions
− Which objects should be modeled?
− Constraints / conditions on values?
− BOM calculation
− Use of variant tables
− Use of certain variant functions
− …
Might be very company-specific!
36. Code Generation
Task: map myCML models (instances of your
metamodel) to VCML models
● Respect your target architecture
● Either generate VCML as text
− Model to text transformation languages
− e.g. templating languages or frameworks
● or generate VCML as data structure
− Model to model transformation languages
− e.g. Java, Eclipse Xtend
37. IDE Adaptions
● Xtext-based editors are highly extensible and
configurable through dependency injection
using Google Guice without modifying
framework code.
− Implement your desired behaviour by subclassing
standard implementations.
− Bind your defined subclass using dependency
injection.
● Nearly each part of system can be adapted and
replaced.
40. Is This a New Idea?
No, in software engineering this idea is called
Model-Driven Software Development
● Huge number of frameworks, tools,
knowledgeable people, … exist.
● Current trend is to go from general UML models
− to Domain-Specific Modeling
− using Domain-Specific Languages
41. Extending VClipse vs
Own Modeling Language
● With VClipse, you can start small.
− Need to learn only the required parts of the
technology stack to implement
− Usable with minimal training effort
● Possible improvements are bigger with own
modeling language approach.
42. Experiences at NSN
● Own modeling language (CML) used for 2/3 of all live
product models
● Fully integrated side languages (UI, help texts, testing)
● Semi-automatic migration from legacy configurators
● VClipse mainly used as a backend to ConfigModeler
● Manual VCML editing mainly used for prototyping
● NSN-specific extensions to VCML just recently
implemented
● Modelers even implemented a third level
(they generate CML for certain classes of products)
43. Summary
● Eclipse-based external textual modeling
environments
● Various possibilites to extend VClipse
● Build own textual modeling language on top
● MDSD approach applied to product modeling
● Modern frameworks like Xtext allow quick
implementation
● Approach successfully in production at NSN
44. VClipse - Try It Out
● Ready-to-run from memory stick
● Eclipse 3.7.2 (Indigo) for Windows 32bit / 64 bit
● VClipse installed
● configured for CWG sandbox use
● VClipse sources – ready to change
● Sample workspace