Form Control & Source Control - Why both?

NOTE: Please move to the correct forum if I posted incorrectly. Wasn't sure where this should go.

We are implementing Form Control with our CSI installation & have Subversion for a code repository. I've been successful in configuring all services & can see files being versioned correctly. While everything is working as expected, I'm a little confused as to why you would attach a Source Code Control service.

It looks like all changes committed to the Subversion repository act as an external archive. Changing any data inside the SVN repo directly does not get replicated back into Form Control (which I can see as both good and bad).

As a test, I did try removing Form Control and use using Source Control which did work but lost Get, Unlock, Archive, and Restore options.

Did I configure something incorrectly, or is this how a software repo is designed to work with CSI? I can work with it either way, but I'm in the process of laying out the server configuration and don't want to have to go back and redo it.

Find more posts tagged with

General Discussions

Accepted answers

All comments

Stephen Cena

I slept on this, checked some things out, and I think I see what's happening: you truly need both.

Infor's "Form Control" marches forever forward. Versions go forward, but there isn't a way (at least that I see) to revert to version 2 from 10 via "Form Control".

Attaching Source Code Control to this, you pick this up. So worst case, you extract a previous version from your repo. Check out the affected file, import over it, and check back in. Not the cleanest, but I can at least see that I have a fully accessible history of my IDO's, Forms, etc.

Please comment if I'm either wrong or if you have any other suggestions.

unknown

That is one of the reasons why I don't use Form Control. If I keep the XML exports in my Azure DevOps repository, at any time I can see a code diff between two versions of a form (in XML) and can pull out a specific version to import back into CSI. I don't worry about having a separate check-in of the Form Script, because it is included in the Form's XML code. I also don't have to go through 12 steps to revert back to a past version of the form. For IDOs, it makes even more sense, because IDO versions always go up, not back. So if you don't keep them in a repository like Azure DevOps, you can't tell if the current IDO version is a newer or older version of the IDO.

com_proactive_201005.pdf

Stephen Cena

Yeah; I'm trying to work out the "best way" to introduce version control without making it too cumbersome and introducing errors. I've gone through projects where the methods/repositories weren't clearly laid out & it hurt in the long run.

We have a problem here of work being done in various environments and manually backing up files.

unknown

I would suggest you always need Form control in any active development environment to handle developers checking in and out development items. Form control is a prerequisite for source control which is optional.

Form Control is like IDO check in/out.

It is used to check-out a form/string or other component for development which locks it in a multi-developer configuration to one developer.

Once the developer has completed their work they can check-in any related form components using form control.

At this point the components the developer has been working on are published and available for other users to test, and viable for export using the deployment form / form sync (whichever you prefer).

Form control effectively handles a development lock within the Mongoose/CSI database for in-progress items.

Items which are locked out and changed are not sent into source control, it is only when they are checked in using form control that the developer is prompted to provide commit text, and all the changes hit the connected repository.

Source control is optional, you don't have to use it, but it can be useful to keep a history, and if you choose to package changes directly from source control. Mongoose/CSI was not designed with a sync-from-source-control feature so packaging from source control is something you need to do manually if needed (it usually isn't).

Source control is only intended for local or on-premise development environments, if you develop in the MT cloud use check-in/check-out to manage who has items locked for development, and deliver changes from DEV > TRN > PRD using the deployment form.

SVN/TFS has a simple commit model, all commits are made direct to the repository server. Once an item is checked-in from form control, Mongoose/CSI commits AND pushes the change and it is available on the repository.

GIT is a distributed development model with commit and push being 2 x separate steps. This can make it more difficult to manage if you have a central dev environment. When you check-in an item, Mongoose only commits the change to the local working copy. It is necessary to review then manually push committed changes to the GIT server.

This means you might need to consider scheduling a push on the development server IF you choose GIT over SVN.

So SVN/TFS is easier to setup if you have a central on-premise dev environment with a group of developers all hitting the same environment, if your developers are distributed and tend to use local environments to do development then GIT with the distributed development model is a viable option.

Just bear in mind that distributed developers and databases can be difficult to keep in sync unless you can automate the building of dev environments direct from source control, having a central dev environment, and dealing with the occasional lock is often easier for smaller teams.

Stephen Cena

Lee - This is helpful. I opted for Subversion because it was directly supported by CSI. Plus; we're a 1-3 person development team at most. Form Control isn't the best but I like the fact it is completely inside CSI. I don't need to worry about performing an export/etc. I'm trying to keep everything as simple as possible for anyone who comes on board.

The issue I can see biting me is the Developer Licensing. At $10k/pop that's going to be a tough sell. So far, it's looking like:

-Form Control enabled in CSI

-Source Code Control attached via SVN for both Form Control and IDOs

-Visual Studio for all database work & use SVN via VS2017 to control SP's, Triggers, etc. I'm attempting to use Redgate again now. I'm up against memory issues and I'm limited on how I can mitigate that. Infor dropping support for "direct server access" will help mitigate this need if I can convince all developers to forget SSMS exists & use the tools provide via Infor UI.

One thing I have noticed from talking with Infor customer developers, is this seems to be an area a lot of people overlook. Anyone else feel like this?

unknown

In our case I'm still the only one doing developments, besides the developments we order to our implantation partner. So it's still manageable with an Excel list of development details, and backups with date and "pre-dev#xxx" appended in the name (I export the form definition with FormSync and restore it in case of major mongoosery), all backups in the same server directory.

I've never used FormControl (didn't even notice it) and did not intend to use Souce Control with CSI since the whole system is so ill-designed and has bits wandering everywhere... I did not think it was really able to support source control until I read this thread.

We don't even have a _Templates database so it looks I cannot even use FormControl(?).

BTW we also use CSI 9.01.01, first GoLive early June this year, and planning on upgrading to 9.01.10 in a few months for the second GoLive adding new modules (multisite, service, quality, etc.). Version 10.x does not yet seem ready enough.

I was initially pushing for cloud but the rest of the project team really wanted on-premise; and boy am I glad that they did, because without easy access to SQL/SSMS, and having been forced to use the WebClient, we probably would have switched to another ERP.

Also I'm learning a lot with all these discussions, thank you all!

Stephen Cena

Florent - You can add a Templates database at any time to your installation. The same goes for Forms databases. We're a shared environment here (one Forms DB and Objects DB shared across all sites). If you wanted to used Form Control, my guess is you'd need to create at least 5 DB's total (assuming 1 site or 1 shared Forms/Objects DB).

-1 _Templates DB for your run-time DB (your main Form DB)

-2 _Template DB's for Fom Control (1 Master, 1 Archive)

-2 _Forms DB's for Form Control (1Master, 1 Archive)

In 9.01.X, the directly supported Source Code Control systems are Visual Source Safe, Team Foundation Server and Subnversion. VSS has long since been dead, and there is a charge for TFS. Subversion is fully functional in its free version and if you're a single dev, it would work well. Training/maintaining/administering the server clearly would need to be dealt with. As Tim pointed out, you can use other systems but that can require more work depending on the solution you choose.

For my money, Form Control is useless without version control behind it. Yes, it will prevent simultaneous Form/Object/etc edits but it doesn't really offer any "protection"/re-visioning. With SCC behind it, if I needed to go back to version 2 of a Form and I'm currently on version 10 I can do that (with mild work involved). It also gives you a secondary back up of all your work: one inside CSI and one outside.

-------------------------------------------------------------------------------------------

SLIGHT TANGENT: I'm still working out a solution for version controlling our actual databases. We purchased Redgate for this task but it hasn't been able to handle the databases (which I find ridiculous as I'm not trying to version the actual data [but you can if you wanted to]). My reason for wanting this is to help with patches. If I can have SP's, Triggers, etc. controlled then I can very easily compare a previous version to a new one. Currently, it's looking like I may have to switch to Visual Studio 2017 and recreate the SSMS folder structure in a solution. Then, add the modified elements one by one. This isn't TOO terrible a solution but still investigating.

Copyright © 2025 Infor. All rights reserved.