This document describes Dan Mauk's company Star Cutter's process for evaluating Syteline software patches before applying them. It outlines how their process has evolved from using customized scripts for each patch, to a hypertext application to manage scripts, to now incorporating a third-party file comparison tool. The tool allows high-level comparisons of code and helps move any necessary changes into their custom modifications. The summary also provides details on how they evaluate patches for various audiences like project managers, developers, and end users.

1. Nashville 2015
Syteline Patch Evaluation
• Dan Mauk, System Analyst, Star Cutter Company
(You can never be too paranoid)

2. A little about our environment
• 3+ years with Syteline
• 140 licensed users
• Single Database Server / Single Utility Server
• 24 Application Databases / 8 highly transactional, some 24/7
• 4 Entity Databases
• Single Forms and Objects Database
• 200+ itemized Modifications
• Currently on Syteline 8.03.11 – about 2 years
• 200+ patches applied to this version
• 8 Physical locations

3. How our Patch Evaluation evolved
• Where we started
– Scripts and Queries customized for each Patch
• Difficult and time consuming
• Second Phase
– Hypertext Application to manage the Scripts
• Allowed us to rapidly evaluate multiple patches
• Where we are today
– Incorporated a 3rd Party file comparison tool
• High level comparisons that aid moving changes into Modifications

4. Audience for Patch Information
• Project management
– 20,000 foot view of patch
• Application Knowledge Experts (AKE)
– Fixes included in the patch
• Developers/Programmers
– Modifications touched by the patch
• System Managers
– Impact on operations during patch
• End Users
– Mostly when will it be applied

5. Why spend time Evaluating Patches
• Detect Impact on Partner Solutions.
• Determine follow up steps needed.
– Not all deliverables will touch your environment.
– Add or remove Partner Solutions for follow up.
– Knowing exactly what to re-applied reduces down time.
• Modifications may need changes to align with patch.
– Possibly learn how to move changes to Modifications.
• Reduce Downtime.

6. Questions to be answered
• What does the patch fix?
• What does the patch “touch” in Syteline?
• Will Modifications be affected?
• Why are only some of the deliverables applied to
our system?
• Are 3rd party products involved?
• Are there post-patch activities?

7. Anatomy of a Patch
Cover Letters
XML list of deliverables
CSV list of deliverables
Zip file deliverables

8. What does the patch fix?
Cover letter main table

9. What does the patch “touch”?
Cover letter “areas” tables
Or listed in the .csv and .xml files
Or listed in the .log after run in log only mode

10. Will Modifications be affected?
Query for Stored Procedure Modifications

11. What about Modified Forms?
Query for Modified Forms

12. Why are only some of the deliverables
applied to our system?
Query for previously patched items

13. What is inside a log file?
• Header
– Main interest is Options Settings
• Pending Tasks
– This area will report what will and will not be applied in a patch

14. Demo Hypertext Evaluation Tool

15. THEIRS
The version delivered
with the patch pulled
directly from the ZIP file
BASE
The version extracted
directly from the App
Database
YOURS
The EXTGEN version
pulled directly from the
App Database
MERGED VERSION
The results of comparing the three files above and merging the differences,
mostly automatically but under user control

16. Patch Evaluation Evolution
• Where we started
– Scripts and Queries customized for each Patch
• Difficult and time consuming
• Second Phase
– Hypertext Application to manage the Scripts
• Allowed us to rapidly evaluate multiple patches
• Where we are today
– Incorporated a 3rd Party file comparison tool
• High level comparisons that aid moving changes into Modifications

17. Nashville 2015

18. The remaining slides in this deck
are provided in case the ability
to Demo is unavailable and for
those not able to attend the
presentation.

19. Select an
environment
to Evaluate

20. List of all XML
files on
environment

21. List of all XML
files on
environment
Filter by
date
applied

22. Patches
Applied
that date

23. Patches
Applied
that date
Selecting a
patch
displays
logs
Cover letter
appears

24. Patch
deliverables
appear

25. Potential
Mods
appear

26. Patch
History
appears

27. Select Patch
Log to view

28. Patch Log
options
appear

29. Applied
Items appear
green and at the
top of list

30. Not Applied
Items appear
yellow and at
the bottom of
list

31. Target
pull-down lists
all DBs code
was applied to

32. View
Full Log

35. Configure each
environment
Filters help
identify Mods

36. Email settings so a
Summary can be
emailed after
completing the
evaluation

37. Attached
Cover
Letter
Body of email
contains the
contents of
the “tabs” in
the Hypertext
application

38. Miscellaneous settings to support
advanced features

39. Some more advanced features

40. Compare
delivered
code to
current

41. New version
pulled from
ZIP file
Current
version pulled
from App DB

43. What about
comparing
Forms?

44. Incoming
pulled form
ZIP
Current Vendor
version pulled
form Forms DB

45. Incoming changes

46. Exposed Partner
Products not detailed
in the Cover Letter

47. What can we do with Modifications?

48. The Evaluate button
shells to a three
way compare; New
to Existing to
Modified and will
Merge to a updated
version of the
modified. Much like
FormSync.

49. THEIRS
The version delivered
with the patch pulled
directly from the ZIP file
BASE
The version extracted
directly from the App
Database
YOURS
The EXTGEN version
pulled directly from the
App Database
MERGED VERSION
The results of comparing the three files above and merging the differences,
mostly automatically but under user control

50. Red
indicates
a conflictConflicts
default to
the BASE
The BASE
included in
the Merged
version

51. Blue
indicates a
resolvable
difference
This
defaults to
the
difference
The Difference
is Merged to
the new
version

52. What about Forms?

53. Let’s take a look at
CustomerOrderLines

54. THEIRS
The new Vendor version
delivered with the patch
pulled directly from the
ZIP file
BASE
The Vendor version form
pulled directly from the
Forms Database
YOURS
The Site version form
pulled directly from the
Forms Database
MERGED VERSION
The results of comparing the three files above and merging the differences,
mostly automatically but under user control

55. Differences Merge
to new version

56. Patch Evaluation Evolution
• Scripts and customized for each Patch
– Difficult and time consuming
• Hypertext Application to manage the Scripts
– Allowed us to rapidly evaluate multiple patches
• Incorporated a 3rd Party file comparison tool
– High level comparisons that aid moving changes into
Modifications

57. Nashville 2015
• Dan Mauk, System Analyst, Star Cutter Company