Configuration Principles with Object Dependencies

Transcription

1 Configuration Principles with Object Dependencies 2014 North American CWG Conference Rick Servello

2 Relentless Commitment to B2B Excellence. DIFFERENTIATORS COMPANY Domain Mastery Industry Recognized Thought Leaders Trusted C-level Advisors No Excuses Delivery Model Independent, successful, and profitable since 1999 startup 4 Partners ALL Hands-On Practitioners 50+ EE s core skills/deep domain expertise Proven ecosystem of expert specialists CORE COMPETENCIES INDUSTRY EXPERTISE Industrial Manufacturing High Tech Heavy Equipment Medical Devices Food & Beverage Power & Energy SAP SOLUTION COVERAGE Variant Configuration Project Systems CPQ Applications Integration hybris/ssc early adopter Variant Configuration Experts Configuration Architecture Commerce Strategy and Road Mapping Integration and Optimization Systems and Knowledge Integration 100X Best Practices from 100+ SAP Implementations elogic.com Victor, NY

3 Understanding Object Dependencies

4 Object Dependencies The rules for how VC objects interact. Preconditions (Boolean) CU01 Select Conditions (Boolean) CU01 Procedures (Imperative) CU01 Constraints (Declarative) CU21

5 Object Dependencies Imperative (Non-Declarative) Logic A step-by-step list of commands to follow. Computations in terms of imperative statements. Must specify sequence. Sequence matters for execution. SAP: Procedures Example Languages: Basic, C, Fortran

6 Object Dependencies Declarative Logic Expresses what the program should do, not how. Declare relationships code engine enforces it. Cannot specify sequence. System determines the execution. SAP: Constraints Example Languages: RegEx, XAML, Prolog, SQL

7 Solving Simple Problems

8 Solving a Geometry Problem Here we have a spec for a Geometry problem: Area (A) Perimeter (P) How would you solve the all dimensions of a rectangle with Procedural Logic?

9 Solving a Geometry Problem What you would expect User enters length User enters width Area = Length * Width Perimeter = (2*L) + (2*W)

10 Solving a Geometry Problem (Procedure) AREA = LENGTH * WIDTH IF LENGTH SPECIFIED AND WIDTH SPECIFIED, LENGTH = AREA / WIDTH IF WIDTH SPECIFIED AND AREA SPECIFIED AND WIDTH > 0, WIDTH = AREA / LENGTH IF LENGTH SPECIFIED AND AREA SPECIFIED AND LENGTH > 0, PERIMETER = ( 2 * LENGTH ) + ( 2 * WIDTH ) IF LENGTH SPECIFIED AND WIDTH SPECIFIED. What about finding the Area when only Perimeter and Length is specified? W = ( P 2L ) / 2 A = L * (( P 2L ) / 2 ) and more

11 The Specs have changed! Length (L) Width (W) Area (A) Perimeter (P) Height (H) Volume (V) Aspect Ratio (R) Aspect Ratio = Length / Width

12 AREA = LENGTH * WIDTH IF LENGTH SPECIFIED AND WIDTH SPECIFIED, LENGTH = AREA / WIDTH IF WIDTH SPECIFIED AND AREA SPECIFIED AND WIDTH > 0, WIDTH = AREA / LENGTH IF LENGTH SPECIFIED AND AREA SPECIFIED AND LENGTH > 0, PERIMETER = ( 2 * LENGTH ) + ( 2 * WIDTH ) IF LENGTH SPECIFIED AND WIDTH SPECIFIED, VOLUME = ( LENGTH * WIDTH * HEIGHT ) IF LENGTH SPECIFIED AND WIDTH SPECIFIED AND HEIGHT SPECIFIED, HEIGHT = VOLUME / AREA IF VOLUME SPECIFIED AND AREA SPECIFIED AND AREA > 0, RATIO = LENGTH / WIDTH IF etc. Solving a Geometry Problem L = A / W W = A / L L = R * W W = V / ( L * H ) H = V / A V = L * W * H V = A * H A = L * W R = L / W P = ( 2 * L ) + ( 2 * W ) P = ( 2 * R * W ) + ( 2 * W ) W = ( P ( 2 * L ) ) / 2 A = L * ( ( P ( 2 * L ) ) / 2 ) (The Hard Way)

13 OBJECTS: X IS_A (300)GEO_MODEL WHERE A = AREA; L = LENGTH; W = WIDTH; H = HEIGHT; V = VOLUME; P = PERIMETER; R = RATIO RESTRICTIONS: A = L * W, V = L * W * H, P = ( 2 * L ) + ( 2 * W ), R = L / W INFERENCES: L, W, A, V, P, H, R Solving a Geometry Problem (The Simple Way)

14 Solving a Geometry Problem Example 1

15 Solving a Geometry Problem Example 2

16 Constraints As powerful as they are, Constraints have limitations: Cannot set default values on characteristics. Cannot evaluate null or not specified. Cannot perform iterative or sequential calculations. Cannot call PFUNCTIONS. Can only handle 64 arguments per constraint. Cannot use not equal to infer Restrictable Characteristics. and more

17 Solving Advanced Problems

18 US States West of the Mississippi: Washington (WA) California (CA) Oregon (OR) Nevada (NV) Idaho (ID) Utah (UT) Montana (MT) Wyoming (WY) Colorado (CO) North Dakota (ND) South Dakota (SD) Nebraska (NE) Kansas (KS) Minnesota (MN) Iowa (IA) Missouri (MO) Arizona (AZ) New Mexico (NM) Oklahoma (OK) Arkansas (AK) Texas (TX) Louisiana (LA)

19 The Problem: We need to plan a trip! The Requirements: We want to fly to the first State and then drive to visit two additional States. The states should all be different. Since we re traveling by car, connecting states must be adjacent to each other.

20 For instance Washington (WA) California (CA) Oregon (OR) Nevada (NV) Idaho (ID) Utah (UT) Montana (MT) Wyoming (WY) Colorado (CO) North Dakota (ND) South Dakota (SD) Nebraska (NE) Kansas (KS) Minnesota (MN) Iowa (IA) Missouri (MO) Arizona (AZ) New Mexico (NM) Oklahoma (OK) Arkansas (AK) Texas (TX) Louisiana (LA)

21 Our First Approach Let s use a Variant Table to help define relationships. Column 1: State Column 2: Adjacent? (Y = 1, N = 0) Column 3: List of States

22

23

24

25 Our First Approach OBJECTS: X IS_A (300)ST1 RESTRICTION: TABLE ST_STATE_PROXIMITY ( ST_STATE1 = X.ST_FIRST_STATE, ST_ADJ = '1', ST_STATE2 = X.ST_SECOND_STATE), TABLE ST_STATE_PROXIMITY ( ST_STATE1 = X.ST_SECOND_STATE, ST_ADJ = '1', ST_STATE2 = X.ST_THIRD_STATE) INFERENCES: X.ST_FIRST_STATE, X.ST_SECOND_STATE, X.ST_THIRD_STATE. OBJECTS: X IS_A (300)ST1 RESTRICTION: TABLE ST_STATE_PROXIMITY ( ST_STATE1 = X.ST_FIRST_STATE, ST_STATE2 = X.ST_THIRD_STATE) INFERENCES: X.ST_FIRST_STATE, X.ST_THIRD_STATE. CONDITION: X.ST_FIRST_STATE = X.ST_THIRD_STATE RESTRICTION: FALSE OR

26 It works!. But is there a better way? (Hint: the answer is Yes)

27 A Multi-Level Approach Our solution solves for exactly 3 States What if the user wants to specify the number of States? Travel KMAT How many Stops? State State State State State State What Stop Number Am I? What State Am I?

28 A Multi-Level Approach OBJECTS: X IS_A (300)STS, Y IS_A (300)STS CONDITION: X.ST_STOP = Y.ST_STOP - 1 RESTRICTION: TABLE ST_STATE_PROXIMITY ( ST_STATE1 = X.ST_STATE, ST_ADJ = '1', ST_STATE2 = Y.ST_STATE ) OBJECTS: X IS_A (300)STS, Y IS_A (300)STS RESTRICTION: Y.ST_STATE <> X.ST_STATE INFERENCES: X.ST_STATE, Y.ST_STATE

29 Configuration Principles to consider for Solution modeling Scalability / Modularity - How much rework is needed to expand? - What parts of this solution can be re-used? - Think about the future! Maintenance - Oops, did I just require all future models to be maintained by someone with a developer key? - Choose native SAP solutions over Z functions! Performance - How many lines of code did it take to solve it? - Did I ask the question is there a better way?

30 Your Turn to Talk to Us! Ask questions today & keep up the conversation tomorrow! Talk with us on Learn more on our blog blog.elogic.com Reach out to us

31 Configuration Principles with Object Dependencies If you would like more information on any of the topics in this presentation, please let me know! Example models from today are available in the CWG SAP Sandbox. Feel free to check out our table this week and ask questions. Thank you for your attention and enjoy the rest of your time at the 2014 North American CWG Conference!