Sage X3 SOA Transformation Methodology

Sage X3
SOA
Transformation
Methodology
Process Overview
Guillaume LECLERE
24 March 2014
Sage X3 - SOA Transformation Methodology 1
Agenda
1.0 Introduction
2.0 X3 Class Model
3.0 Prioritizing
4.0 Transformation Strategies

X3 Object Full Transformation
X3 Object Read Only Transformation
Component Transformation
5.0 Tools
UML2 Designers
Call Tree Extractor

SOA Transformation Methodology
Main goal
What we have What we want
X3 ERP
Using an old
techno
What we need
“Syracusation Methodology”
X3 ERP
Syracuse Using Syracuse
New object oriented
framework

A new architecture
Presentation
Presentation Presentation
Presentation
Logic
Logic Logic
Logic
Database
Database
Business
Business Logic
Logic
Business
Business Logic
Logic
3 separate layers Database

Database
Easier to develop, to enhance, to maintain
What are the main principles?
Syracuse architecture
Clear architecture, clear development. 4 Meta Data objects :
Presentation
Presentation Representation
Logic
Logic
Business
Business Logic
Logic Class
Data type
Database
Database Table

What are the main principles?
Syracuse architecture
- The Class contains Properties and all of Business Application Rules, ensuring the
consistency of data in tables
Example: the sale date is equal or greater as the purchase date
- The Representation describes the way that Class Properties are shown to the user
and contains code to help him/her to enter data
Example: when an item is entered, the default price field is filled
- The Class must be developed and tested without Representation, but it’s possible
to create a basic Representation without any code to help

Scope
It’s important not to confuse “Syracusation Methodology” and “Developing using

Syracuse”: what we call “Syracusation” is the fact to rewrite existing X3 ERP
functions using Syracuse.
New function
PRD SPECS DEV
Existing function
Business
SPECS DEV
rules
Syracusation Methodology Syracuse Development Rules

General Overview
X3 w/previous Business Logic

Modelization X3 Class Model Specifications Development X3 w/Syracuse
techno Extraction
For the whole ERP For each Business Object
First step : X3 Class Model Second step : Development

X3 Class Model
First step of the transformation, the
X3 Class Model is a big picture of
future classes and dependencies.

X3 Class Model
Overview
UML Tool
X3 Dictionnay Modelization X3 Class Model
Dev. Team PBA

X3 Class Model
• The X3 Class Model is an helpful tool for

- Taking good decisions: it’ll give an idea of transformation impacts when an object must be
syracused
- Having a progress view of X3 transformation
- Identification of common classes, i.e. classes used by several modules
- Identification of dependencies
• It is built using the X3 Table Dictionary to be sure to take into account all of our tables
• Using UML 2 class diagram
• No need to detail the properties and the methods, it will be done later during the
classes specification step
• Useful for the SOA transformation, but also after to give an overview of the product

Prioritizing
How to decide which X3 objects are
to be transformed?

Prioritizing
• Driven by marketing needs and by end user experience, not by a 100% Syracuse objective.
Some of back office functions could remain in the ‘Classic’ mode
• First inputs are given by the Product Management, depending on strategic needs and
ergonomic improvements, such as Mobility
• From those inputs and helped by the X3 Class Model the team will prioritize developments,
taking into accounts
- Dependencies between classes
- Technical and ergonomic constraints
• Also it has to be decided if the transformed Object will replace or live with the Classic one.
- In the first case all of calls to the Classic object have to be replaced by calls to the Syracuse one
- In the second case the data model have to remain exactly the same to let the Classic Object
working
- Because we need to give time to our partners to adapt theirs add-ons to Syracuse, it’s strongly
recommended to let both Classic and Syracuse objects working together in at least one
version
Transformation Strategy
How to choose the good way to
transform an X3 Object?

Transformation Strategies
• The way to transform existing code may vary, it depends on needs and priorities
• We can distinguish 3 main cases :
1. Full transformation of an X3 Object: we need a complete CRUD X3 object working

in Syracuse
2. We need to be able to consult, select and control an objet from another, but the
CRUD management stays in the Classic mode
3. We need to use a “component” (i.e. typically a black box receiving data and offering
a service) from a Class

Transformation of X3 objects
Full transformation of an X3 object

Business Logic
Previous Object Class Specification Class Development Class
Extraction
Dev. Team PBA QA
First step
Representation Representation
Ergonomist Representation
Specification Development
PBA QA Dev. Team
Second step

Basic rules
• The Class development must be independent of the Representation development.

It must focus on the data integrity, regardless the way that data are given (U.I.,
Web Service, Import, …)
• The Representation specification can be started before the end of the Class
development process

Class specification
X3 Class Model
Safe X3 Studio
X3 Code
Business Logic Object Business

Specification Class Specification
Extraction Rules
X3 dictionnary
Dev. Team PBA
X3 Documentation

Class specification
X3 Class Model
Safe X3 Studio
X3 Code

Extraction Rules
X3 dictionnary
Dev. Team PBA
X3 Documentation

Business Logic
Extraction
Class specification
• The Business Logic of an X3 applicative Object is in the code and the dictionaries
• The Business Logic Extraction needs to read the code of the X3 Object Processes
• Be careful, some Business Rules are hidden in the UI (see examples on the next slide)
• This work is done by the development team, and requires an high level of technical and
applicative expertise
• Don’t forget to take into account the Entry Points
• Tool in Safe X3 Studio to help
NO FUNCTIONNAL REGRESSIONS

Business Logic
Extraction
Class specification
• Examples of business rules hidden in Classic UI:
• “The field Y is set to blank and is not alterable when the field X has a value” means
“the information Y must be empty if the information X is not”
• “After the modification of the field X with the value A, the alterable field Y is filled by
the default value B” means “if the information Y is empty, it must be set to B if the
information X is filled by A”
• “After the modification of the field X with the value A, the alterable field Y is filled by
the default value B and is no more alterable” means “if the information X is filled by A
the information Y must be filled by B”

Class specification
X3 Class Model
Safe X3 Studio
X3 Code

Extraction Rules
X3 dictionnary
Dev. Team PBA
X3 Documentation

Safe X3 Studio
Tools
Class specification
• Available in Eclipse
• Ability to give n levels of CALL/Gosub from a source
• Ability to gives n levels of CALL/Gosub to a label or subprog
• Ability to gives a “Syracuse compliant level”:

• “Not Syracuse compliant” if using the X3 Object Model
• “% Syracuse compliant” if using global variables, global masks, locks or clalev
• Ability to produce a report or an interactive tree view, allowing to navigate in

sources

Safe X3 Studio
Tools
Class specification
Today it’s done manually, but the development of a tool is in progress

Class specification
X3 Class Model
Safe X3 Studio
X3 Code

Extraction Rules
X3 dictionnary
Dev. Team PBA
X3 Documentation

Object Business
Rules
Class specification
Existing Classic object business rules list
• Done by the R&D Team for the PBA
• The list of field and object management rules
• It’s a working document intended to be used by the Scrum Team
• Written in the most relevant language for the Scrum Team
• Temporary document, not to be maintained after the transformation
• A Word Document, describing the object role, its data model, its links with the other objects
• An Excel Document, giving :

• Field business rules
• Object business rules
• Business actions with parameters, effects and return value
Class specification
X3 Class Model
Safe X3 Studio
X3 Code

Extraction Rules
X3 dictionnary
Dev. Team PBA
X3 Documentation

Specification
Class specification
• Done by the PBA
• Using the Object Business Rules Document

• Do not keep the deprecated business rules or actions
• Take advantage to enhance business rules if needed
• If you need to keep the X3 Classic Object working, keep the same V7 data model.
However if a change is needed:
• Keep the Classic code working
• Think about migration and avoid a complex one
• Taking account of new Syracuse capabilities

• “Service mindset”: think in term of services offered by the object
• What was done for Syrapedia mustn’t influence the specifications

Class specification
X3 Class Model
Safe X3 Studio
X3 Code

Extraction Rules
X3 dictionnary
Dev. Team PBA
X3 Documentation

Class Specification
Class specification
• Must be in English, in a dedicated document
• Must provide the class description and behaviors

• Properties
• Methods and Operations
• Services
• Must provide migration information if needed

Class development
Class Specification Development Class
Dev. Team PBA QA
Following the regular Scrum process, in compliance with X3 development rules

Representation development
Ergonomic and Representation

Development Representation
behavior analysis Specification
Ergonomist PBA Dev. Team QA

Representation development
• Specifications are written in English by the PBA, helped by an Ergonomist,
regardless what was done for Syrapedia
• They must define for each Facet:

• The default organization (sections and blocks for Detail and Edit, column order for
Query and Lookup)
• Which properties are displayed
• Which extra links and menus have to be added to properties, arrays and pages
• Which extra behaviors have to be added to help the user
• Specifications mustn't take into account of authoring. The authoring is a layer on

the Representation
• The development step follows the regular Scrum development process, involving
the development team, the QA and the PO
Transformation of X3 objects
Read only transformation of an X3
object

R/O transformation of an X3 object
• The new framework allows to use Classic X3 functions and Syracuse X3 functions in the same
environment. That’s why it’s possible to develop only a read only class for an X3 object, keeping the
Classic object for the Create, Update and Delete operations.
• Why do we need a Read Only Syracuse X3 class?

• To have selection and control on this object from other classes
• To let the elastic search working on the object: the elastic search need the Detail Representation to show
data
• To have a more integrated “Jump To” and selection into Syracuse functions using this object
• What are the benefits?

• Save time:
– It’s faster to develop a Read Only Class, because we haven’t to take care of the data integrity
– No need to extract the business rules
– there are less Representations to manage
• We have to keep in mind that one day the object will be full Syracuses. The Class definition must take
into account this fact.
R/O transformation of an X3 object
Business Logic
Previous Object Class Specification Class Development Class
Extraction
Dev. Team PBA QA
Representation Representation
Ergonomist Representation
Specification Development
: faster
PBA QA Dev. Team

Transformation Strategy
Components

Components
• Component definition
• A component is a group of programs used by more than one X3 object (or could be)
• It is called by a funprog or a subprog, possibly by a $ label
• It provides a service without direct interaction with the user
• Usually they’re complex
• We have this kind of component in each module

• Automatic journals
• Depreciation calculation engine
• Costs calculation engine
• …

Components
• A good idea is not trying to transform components but to adapt them regarding
the Syracuse constraints :
– No global variable
– No clalev
– No lock
– No masks (except if they are declared and used locally in the component)
– No use of deprecated keywords (see list in GitHub)
– New way to manage errors
• If it’s possible, try to keep the code working with Convergence. For example you
can encapsulate the code in order to declare needed variables and to manage
errors
• If not, the code must be duplicated

Components: encapsulation
This is a Classic code, not Syracuse compatible :

Components: encapsulation
Classic code Syracuse code
Main code
Note: in this example, the MYSUBPROG_CONV should be

named MYSUBPROG to let the calls in Classic programs
work, and so the Main code MYSUBPROG should be named
MYSUBPROG_MAIN for instance
Components: duplication
This is a Classic code, not Syracuse compatible :

Components: duplication
Classic code Syracuse code
The Convergence code is not modified

Duplication vs Encapsulation
Pros:
• Rapidly operational
• « True » Syracuse code
Duplication Cons:
• Need to maintain two codes for the same function until the full updating
Pros:
• The code of the function is shared by Classic and Syracuse code
Cons:
Encapsulation • Risk to have quality issues on both Classic and Syracuse functions
• Not easy to implement
If possible prefer the encapsulation, because only one set of code need to be
maintained

Components
• First feedbacks show that’s the Component transformation is harder than the
Object transformation
• Why?
• Because the development of an Object in the Classic mode or a Class in Syracuse

is strongly guided by the framework. The way to develop is fairly similar regardless
the module or the developer, and it’s easy to apply the same process for all objects
• By contrast, in the Classic mode as in Syracuse, the developer is more free to

choose the way to develop a component, so the code is more different from a
module or a developer to another. Each case is unique and require a deeply
analysis to find the good way to use and to evaluate the workload,

Tools
UML2 designers
Call Tree Extractor in progress

UML2 Designer
UML Tool
• We choose to develop our own UML2 Designer tool and to integrate it as an X3

development tool
• The Sage ERP X3 UML2 Designer is a part of the Syracuse server, diagrams are
stored in the MongoDB database
• It allows to:
• Design Class diagrams and Use case diagrams (Use case diagrams will be available
at the end of April)
• Share diagrams between X3 developers
• Deliver diagrams to the X3 ecosystem
• It’ll evolve:
• Development of State diagrams and Sequence diagrams is planned
• If needed we’ll add the capability to generate X3 Class Metadata from diagrams
UML2 Designer
UML Tool

Call Tree Extractor
Safe X3 Studio
Tools
In progress
• Launched from a Window definition
• Builds a tree of all nodes under the Windows, including process and sub-process
• Allows to add business rules on each node
• Flags on each rule to monitor progress (PBA validation, development status, link
to Unit Tests, …)
• Reports to list all of business rules attached to a Property or a Class

Call Tree Extractor
Safe X3 Studio
Tools
In progress

Call Tree Extractor
Safe X3 Studio
Tools
In progress

Call Tree Extractor
Safe X3 Studio
Tools
In progress

Call Tree Extractor
Safe X3 Studio
Tools
In progress

Sage X3 SOA Transformation Methodology

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Sage X3 SOA Transformation Methodology

Uploaded by

Copyright:

Available Formats

Sage X3

2.0 X3 Class Model

4.0 Transformation Strategies

Sage X3 - SOA Transformation Methodology 2

What we have What we want

Sage X3 - SOA Transformation Methodology 3

3 separate layers Database

Sage X3 - SOA Transformation Methodology 5

Example: the sale date is equal or greater as the purchase date

Example: when an item is entered, the default price field is filled

Sage X3 - SOA Transformation Methodology 6

It’s important not to confuse “Syracusation Methodology” and “Developing using

PRD SPECS DEV

Syracusation Methodology Syracuse Development Rules

X3 w/previous Business Logic

For the whole ERP For each Business Object

First step : X3 Class Model Second step : Development

Sage X3 - SOA Transformation Methodology 8

Sage X3 - SOA Transformation Methodology 9

X3 Dictionnay Modelization X3 Class Model

Dev. Team PBA

Sage X3 - SOA Transformation Methodology 10

• The X3 Class Model is an helpful tool for

• Using UML 2 class diagram

Sage X3 - SOA Transformation Methodology 11

Sage X3 - SOA Transformation Methodology 12

Sage X3 - SOA Transformation Methodology 14

• We can distinguish 3 main cases :

1. Full transformation of an X3 Object: we need a complete CRUD X3 object working

Sage X3 - SOA Transformation Methodology 15

Sage X3 - SOA Transformation Methodology 16

Dev. Team PBA QA

PBA QA Dev. Team

Sage X3 - SOA Transformation Methodology 17

• The Class development must be independent of the Representation development.

Sage X3 - SOA Transformation Methodology 18

Business Logic Object Business

Dev. Team PBA

Sage X3 - SOA Transformation Methodology 19

Business Logic Object Business

Dev. Team PBA

Sage X3 - SOA Transformation Methodology 20

• Don’t forget to take into account the Entry Points

• Tool in Safe X3 Studio to help

Sage X3 - SOA Transformation Methodology 21

Sage X3 - SOA Transformation Methodology 22

Business Logic Object Business

Dev. Team PBA

Sage X3 - SOA Transformation Methodology 23

• Ability to give n levels of CALL/Gosub from a source

• Ability to gives n levels of CALL/Gosub to a label or subprog

• Ability to gives a “Syracuse compliant level”:

• Ability to produce a report or an interactive tree view, allowing to navigate in

Sage X3 - SOA Transformation Methodology 24

Sage X3 - SOA Transformation Methodology 25

Business Logic Object Business

Dev. Team PBA

Sage X3 - SOA Transformation Methodology 26

• Done by the R&D Team for the PBA

• The list of field and object management rules

• It’s a working document intended to be used by the Scrum Team

• Written in the most relevant language for the Scrum Team

• Temporary document, not to be maintained after the transformation