Appian Backwards Compatibility

Transcript

1. Incentive Technology Group – Proprietary Level 1 Backwards Compatibility for Appian 7.X Applications in Production A Paradigm of Best Practices Incentive Technology Group
2. Incentive Technology Group – Proprietary Level 1 Overview • Data Centric • Complex Data Types • Rules and Constants • SAIL Interfaces • Process Models
3. Incentive Technology Group – Proprietary Level 1 Data Centric vs Process Centric • What is data centric design in Appian? • Basic model: • Pull data from client’s RDBMS • Get user input • Persist back to client’s RDBMS • Process Centric is: • Long-lived processes • Relying on in-process memory (K-database)
4. Incentive Technology Group – Proprietary Level 1 Being Data Centric • Use CDTs, not SQL nodes • Flatter CDTs • Smaller CDTs (should not exceed 50 fields) • Do not be over zealous with field constraints (@column mapping in XSD)
5. Incentive Technology Group – Proprietary Level 1 CDTs Post Production • 4 out of 5 architects agree: • post-production CDT changes break prod environments • Do not delete CDT fields • Never change CDT type mappings • Many models/ applications may rely on same CDT • No versioning system creates difficult debugging • (Put XMLs on GitHub) • Better option – make new CDT
6. Incentive Technology Group – Proprietary Level 1 Laying the Ground Rules • Newest version always used (unlike process models) • So… • Making changes can disrupt running processes • Adding new rule inputs won’t register in existing processes • Removing inputs breaks them • Making changes to functionality can alter whole application functionality (true for Constants too)
7. Incentive Technology Group – Proprietary Level 1 Some Good Ideas • Use keyword syntax w/parameter names • e.g., er_DM_expRule(problemInput: ac!problem, solutionInput: ac!solution) • More important for rules with many inputs (i.e., SAIL forms) • Rule/data type passed to expression then deleted? • Impact Analysis won’t catch that; be careful • Give Constants unique names - • On name clash, Constants win
8. Incentive Technology Group – Proprietary Level 1 Speaking of SAIL… • Unfortunately • You cannot add fields to an existing SAIL form • Well, you can, and it will look fine, but that is in fact the problem
9. Incentive Technology Group – Proprietary Level 1 Still SAILing • You need to change the functionality of the process vis-à-vis a SAIL form rule input? Don’t Do This: • Instead, make new rule • Give it related name: • e.g., dm_coolRule, dm_coolRuleRevised • Old processes will use old version; new processes will use new
10. Incentive Technology Group – Proprietary Level 1 Final Thoughts on SAIL in Production • Your client will want changes that will impact SAIL forms • You should not change SAIL form rules • Unless the changes are only cosmetic, then… • Go for it! • Functional changes require replicating the rules and then adding changes • Lastly, comment out sections and document everything! • /* */ - just like JavaScript
11. Incentive Technology Group – Proprietary Level 1 And the reason for all of this difficulty is… • Process models are both: • Resource Intensive • Unwieldy • An IDE masquerading as a “graphical representation for specifying business processes” • It’s even sold that way:
12. Incentive Technology Group – Proprietary Level 1 So with this in Mind • Smaller process models are your friend • Merge/ encapsulate process flows called more than once • Models easier to keep tabs on than smart services • Smaller process instances requiring fixes post production have smaller footprint on end users • Also, just in general, sub-process oriented design patterns allow better organization • Be careful though… • Passing whole CDTs by reference = game over
13. Incentive Technology Group – Proprietary Level 1 Other Process Model Issues • Adding new required parameters to models used as subs… • Live process instances won’t pick them up • Method required to handle whether/ not sub-process parameters null or empty • Document Everything:
14. Incentive Technology Group – Proprietary Level 1 External Integration: Having a Fault Tolerant Mindset • External integration – almost always necessary • Databases, content management systems, sweet YouTube clips • Break…a lot • Web service calls can time out & URLs can change • Database integrations can fail in Prod • Design for faults using these friendly guys: