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:
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:
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…
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…
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?
Anyone? Maybe a relevant doc/link/tool?
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:
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
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
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...
MiloTsukroff : 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