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.

1. How to Build Your Own
Product Modeling Environment
Tim Geisler
webXcerpt Software GmbH
tg@webxcerpt.com
CWG 2012, Berlin 2012-05-08

2. Product Modeling Environments

3. Product Modeling Environments:
Single Transactions

4. Product Modeling Environments:
PMEVC

5. Product Modeling Environments:
Eclipse-based SME

6. VClipse
● Eclipse-based textual
product modeling
environment
● for VC and IPC
● based on Xtext / EMF
● Open Source
Eclipse Public
License
www.vclipse.org

7. VClipse - VCML
● Textual language for
SAP objects
● Embedded languages
for dependencies
(procedures, conditions,
and constraints)

8. IDE for VCML
Validation
Content Assist
Quickfixes
Cross References

9. IDE for VCML
Outline
TemplatesFolding
Rename
refactoring
Where used?

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

13. Specialized Modeling Environments

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

21. Specifying Variant Functions
import "cstics.vcml" // contains all cstic definitions
variantfunction Z_COPY_DEFAULT_MV "Copy default values (MV)" {
GEN_CSTIC_1_NAME : in CharacteristicNameMV
GEN_CSTIC_2_NAME : in CharacteristicNameMV
GEN_INSTANCE : in CharacteristicValues
}
VCML
Validation
VCML
Templates
CML integration
Java
implementation
stub
Documentation
ABAP
implementation
stub
VCML
Tooltips
Variantfunction
object
Generating Artifacts:

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

25. Example: ConfigModeler @
RFC
Editor/IDE
Editor/IDE
ConfigModeler
VClipse
CML
VCML
Code Generation

26. ConfigModeler – Initial Idea
StandardizedStandardized
productproduct
descriptionsdescriptions
FormalizedFormalized
productproduct
descriptionsdescriptions ConfigModeler + VClipse
Eclipse-based IDEs
code generation
CML as
specification and
documentation language
CWG 2010 Vienna
CWG 2011 Cologne

27. ConfigModeler – Languages
CMLUI: User Interface
CML: Product model
CMLT: Test cases

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

31. Editor/IDE
my ConfigModeler
myCML
my Code
Generation
Grammar
Metamodel Scoping
Validation
Target
Architecture
Code
Generation
VClipse
Adaptions
Exports /
Reports
Graphical
Views
Import from
Legacy
Configurators

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, ...

33. Defining your
Modeling-Language Metamodel
Represents all product models in the domain
(like a schema)
● EMF Ecore Meta Model
● Generated from grammar or defined separately
● Source of transformation

34. Scoping
Visibility of Objects for Cross References
The implementation (really that short!):

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.

38. Effort

39. Effort
● Prototype for small language can be build in
about a week

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