Customization-tracking tools and patch impact management

What are the tools you use to manage your various customizations (Mongoose Forms, IDOs, Reports; SSRS; SQL SPs, Tables, UETs, etc.)?

And how do you use them to assess patch impact?

I need to find a better way to manage all this and need your recommendations.

So far, I've been describing my customizations in an Excel (Google Sheets) file, in which each tab is a Form (at first) or a Customization (when several Forms/IDOs/SPs/etc. are involved).
This system is becoming messy, being live with CSI for one year already; it's not enough now, since:

  • there are too many tabs
  • the same Form may appear in several tabs
  • there's a second admin/developer now
  • I have a growing list of patches awaiting impact assessment and testing (too time-consuming and messy)
  • we're starting Phase 2, adding Factory Track, Multi-Site, QCS, probably Service, etc.; so new modules, new DBs...new problems!

We're using CSI 9.01.01 on-premise.

I've heard of Form Control; I've seen that Source Control tool can be linked to a User, and that Form Scripts can be automatically opened in Visual Studio (2013/2015).

What are the best options:

  • VisualStudio+GitHub for tracking?
  • FormSync, log-only mode for patches and any diff tool to assess patch impact?
  • Anything else? Where does Form Control come into play in all this?
  • LOL. Sorry, I guess this is/was a serious question. The short answer is, there are no good options. Certainly not a comprehensive tool that captures all enhancements, versions them, lets you revert back to a previous version, or any of the goodness a good modern day .NET Core project would do for you. Just a hodge-podge of tools that half-work, only work on-premise, and are frankly more work then they are worth.

    What do us "pros" do?

    We create a folder structure:

    • Deploy
      • Form
      • IDO
      • UET
      • DataView
      • Component Class
      • ...

    Using the various tools (IDO Export, App Metadata Transport, Form Sync, Excel export), you painstakingly export out each object separately as either an XML file or a CSV file depending on what the tool provides or in case of no tool, the form grid contents (UETs, Events, Background Task Definitions).

    That folder structure is put in a shared location and each developer is responsible for keeping it up to date and backing up the files before they change or merge code into them.

    If you are fancy, you put that folder structure into a "Shared Project" project type in Visual Studio and then check-in/out into a Git repository like Azure DevOps.

    When you are ready to deploy, you basically do the reverse process to import all those objects back into CSI. Making sure to follow a dependency order of import - Component Class, Property Class, Data Maintenance Wizard, UETs, IDOs, IDO Custom Assemblies, Events, Strings, Images, Forms, etc...

    Oh, and then you figure out how to fix your site when Form Sync comes along and breaks everything. Hope you have a copy of Beyond Compare to do 3-way merging...

  • Thank you!

    That's already what I told previously and that confirms my approach Slight smile

  • Thanks, although quite depressing... heheh.

    Is FormControl of any help?

    Also, for the second part of my question: how do you analyze the impact of a patch before applying it?

  • Form Control... No. Hasn't been kept up-to-date with changes in source code systems or Visual Studio editors. In typical Infor fashion, they are re-creating the wheel and trying to roll their own.

    For patches... You read the cover letter. Then you extract the patch and actual look at what it is going to apply - they don't always match. Then you use a good text editor like Beyond Compare to do see what actually is changing. 

  • You have the list of elements impacted by the patch in the release page.

    You check your environment if you have site/group/user version.

    If not, go.

    If yes, analyze what you did, compare, merge, pray Slight smile

  • The problem of patch impact was an issue at a couple of prior employers.  (My current employer has a different approach: No, we don't do patches.)  I made up a spreadsheet to track the time it would take to apply a patch.  It was rough, but it did give an order-of-magnitude estimate, a bit better than a guess.  Each type of change was given a time value. Then the number of each changes would be researched and inserted.  There were different time values for customized objects, like forms and files, so that if a CTP hit a form that we had customized, that would affect the estimate.  Usually forms that were not changed were given little to zero time.  Anyways, it was a work in progress and I never really got it totally accurate, but it was a very good tool for knowing when to say, Wow, this CTP is gonna be a doozy to apply! 

    My guess is that this approach can be extended to other kinds of changes. 

  • Thanks all...

    : Could you elaborate a little on this spreadsheet to track estimated time required for a patch? Any rules or base elements? 

  • I wrote it all up in 2006, when I left a company which was subsequently bought, and then they abandoned most of their Lawson install.  If you want, I can send it to you via my home email, milotsukroff @ netscape.net  Just let me know.  If may still have some value to you.  I tried to cover every type of customization available at that time; it does not cover web-based components.

  • I guess this also doesn't cover Mongoose reports using FlexLayout etc... since it was not in place 2006 :) and this is really time consuming!! (with certainly others subjects, but I will not try to find which one lol).

    Thank you

  • I'm dealing with this right now & it's making me nuts. Infor hasn't really done much on the "developer side" to make these things easy for us (IMO). There's definitely going to be a bit of "roll your own" involved in any solution you come up with. (Tim's explanation is probably the best I've seen so far). Things I've seen/done/noticed/rambling in no order

    • FormControl by itself is "useless". It does offer you 'version control', just one version. If you tie your CSI configurations to a supported Source Code Control platform (SourceSafe (DONT), Subversion, Team Foundation). You can truly version control your Forms, Objects, etc. The downside is there is no way to track/group change sets. Yes, you're getting versioned copies but there isn't anything that groups them together. Another downside to FormControl is that only "sa" can run it unless you pay for Developer Licenses. Depending on how your environments are set up and the # of devs, this isn't going to work.
    • For SQL Server, we're attempting RedGate source control. It ties version control directly into SSMS and lets you version control your database schemas and/or data. The problem I've found w RedGate is it's only 32 bit & with the size of  Infor's structures it can take a LONG time just to check in/check out. dbForge has a similar issue, but they at least make their own stand-alone 64bit tools as well as 32bit add ons for SSMS.
    • For on-hand tools, this is what I have in my belt:
    • For assessing impact of patches, I use the "log first" option of the patch & read the logs. This way I at least have some idea of what it's going to change. Then using the various tools outlined, I do compares to find out the impact.
    • For Forms issues, I use the Export feature in the FormSync program not the Form. The program will export into XML which is substantially easier to read and/or edit.
      • When editing Forms always use Form --> Definition --> Design and then select the Form to edit. This prevents and "post load" events from firing and "polluting" your Form data.
      • Try to use the Object Explorer on the left hand side of the pane for finding Objects versus clicking on them inside the Form. Sometimes if you breathe wrong on a component, it thinks you changed it. This helps keep it to a minimum
    • The hardest one: Try to do your customizations in 'upgrade friendly' ways. Some suggestions:
      • Place a button to open a 'child form' that holds all your customizations
      • Use a GroupBox to contain all your customizations on a Form
      • If you have to modify Infor FormScripts, try to keep all your customizations in separate methods if possible (almost like an ExtGen) and insert a single method call in the Infor code to call your method.

    Ok, I think that's enough pre-coffee nonsense from me this morning :) If I think of anything useful I'll chime in :)

  • Excellent list Steve and that mirrors my toolbelt for the most part. You have a few more tools available to you because you are on premise. No SQL access in SaaS so RedGate doesn't help there. Depending on what version of CSI you are on, the form versions of Form Sync and App Metadata Transport work fine. They work in 10 at least. I upgraded to Visual Studio 2019 awhile ago because I am doing mobile app work using Xamarin.Forms which requires that version. Works fine with CSI. For form development, the recommendation is to put the added fields in a new tab, where applicable. If the form doesn't have tabs... Well, you know which one is going to break.

    In newer versions of CSI (9.01.10+), the stand-alone utilities have procedure-based alternatives available that would allow scripting via the REST API. Some of us are trying to write our own tool to use with those utilities to automate the process better, but it is still a work in process and none of us really have a lot of time to work on it.

  • I'm there with you. I'm so tempted to write my own tools to help "stream line" the process. Just throw it onthe mountain of work I still have to do :)

  • One other thing I forgot to mention:

    If you can get to 9.01.10/11/12, I believe Infor has implemented the 'upgraded' Extend And Replace for Forms. If it works "as advertised" it will allow you to extend an Infor Form (like a C# class), make changes to the Form but updates/upgrade won't get applied. they will get applied to the Vendor version of the Form. You'll still need to go through and fix your Forms but it might help make things more manageable.

    We're still trying to schedule our upgrades here.

  • There is new functionality in the Mongoose toolset that allows you to point at a group of forms and objects and it will package all of the pieces of a solution. Additionally any forms that you include it will package up all of its components: The form, Collections, Sub Collections, Tables, Scripts, Validators etc.  All of this gets packaged into a deployable .zip that can be imported into another environment, even moving from on prem to cloud.  Additionally you can also package up data within tables so that you can move information as well.

    If you are interested in this then check out the Deployments form. There are two uses of the form. One that packages by access as and another that is more free form which allows you to package up the elements freely and even script this out so that you can reexport if you need to.

    Hope that helps

    Paul