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?

Find more posts tagged with

Accepted answers

All comments

Legacy Contributor

Anyone? Maybe a relevant doc/link/tool?

Legacy Contributor

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...

Legacy Contributor

Thank you!

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

Legacy Contributor

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?

Legacy Contributor

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.

Legacy Contributor

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

Legacy Contributor

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.

Stephen Cena

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:
- Notepad++ - https://notepad-plus-plus.org/
- Visual Studio 2017 - https://visualstudio.microsoft.com/downloads/
- SSMS 18.x - https://docs.microsoft.com/en-us/sql/ssms/download-sql-server-management-studio-ssms?view=sql-server-ver15
- RedGate Dev/Server Toolbelts v10 - https://www.red-gate.com/
- BeyondCompare 4 - https://scootersoftware.com/
- Brent Ozar First Rersponder tools - https://www.brentozar.com/responder/
- Remote Desktop Manager Free - https://remotedesktopmanager.com/home/download
- VisualSVN - https://www.visualsvn.com/
- TortiseSVN - https://tortoisesvn.net/
- WinRAR - https://www.rarlab.com/
- SynchronizeIt - https://grigsoft.com/wndsync.htm
- PowerToys from Microsoft - https://github.com/microsoft/PowerToys/releases
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

Legacy Contributor

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.

Stephen Cena

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

Stephen Cena

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.

Legacy Contributor

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

Stephen Cena

I'm definitely going to be looking at this. Just loaded it up & already look promising!

Legacy Contributor

Great discussion, if you have a chance look at Visual Studio Code. It's replaced notepad++ as my go-to editor and has a bunch of plugins, including support for GIT/SVN, built in compare/merge capabilities are good too.

rm_benefit_administration_aca_training.pptx

Legacy Contributor

If you use custom assembly code it can be handy to have some CI/CD infrastructure to take the compiled dll/pbd and turn it into XML metadata for import.

routines like this can help when you have built a library of re-usable functions and want them built from source to take them from dev environments to prod.

[View:/cfs-file/__key/communityserver-discussions-components-files/91/7140.Set-AssemblyImageInMetadata.zip:320:240]

Legacy Contributor

Yeah, except it broke as of the May update. It won't let you import the zip file it creates anymore. Plus it also doesn't capture UETs, Events, Background Task Definitions, DataViews, and a lot of other stuff that developers and power users create as part of an overall enhancement to CSI.

VDA_INVOIC_Web-Checker.pdf

Legacy Contributor

The reference to the limit of access to the FormSync form - while true if you only access from the application - is not taking into account the ability to access FormSync from the Utility server if you are on-prem.

I have, also, supported changes by keeping a folder with change per type (forms, IDOs, SPs, etc.) and a log of changes - sometimes with details for a standard form that has had more personalizations than any of us would have wished. For potentially tricky installations of personalizations I also recommend a specific document for that project so that changes moved into production in the right order/allowing for dependencies. Yes, it's manual, but it works for companies with 1 - 3 developers. More people than that would likely fail and increases the chance of unknown overlap.

Copyright © 2025 Infor. All rights reserved.