I am hearing more and more talk about the stored procedures in Infor CSI eventually being ported over to Handcoded (.NET) methods (somebody feel free to correct me if I am wrong).
Also, the Development Best Practices document from the Mongoose Portal would prefer that custom code, if there is a need for it, should be done with Form Scripting (Client) or IDO Extension Class (App Server).
We currently have quite a bit of custom code in the form of stored procedures. I am curious if we should begin looking to port our custom code from T-SQL to .NET code (running on either the client or app server, instead of the db server).
And any new customizations that would require IDO Methods be written, seems like it should be a Handcoded method instead of a Stored Procedure method.
Does anybody have any thoughts or guidance on this subject.
BTW, we are currently running CSI 9.00.30 with hopes of migrating to 10 in the near future.
We're in the same boat as you are, only 9.01.01 (w 9.01.10 and/or 10 on the horizon). This is my opinion on it:
With the announcement of the change (.NET and Mongoose reporting) paired with Infor's cloud offering of CSI, we're going to be migrating everything over to IDO Ext Classes/FormScripts and Mongoose reporting. My understanding is if you remain on prem you can get away with stored procedures a little longer. My person take is: while Infor says an on prem solution will be provided you don't know when they may change their minds. I'm looking to treat our environment as if we were going to the cloud.
If you have a low-priority project that would require SSRS or an SP, use that as a trial run if you've never worked with IDO Extension Classes or Mongoose reporting. That way if the project stumbles, you're not in any great trouble.
As for where the code should live, I've been struggling with this one. Though there are advantages to each (it's been a while so please correct me if I'm wrong & I can't find the notes I took):
-Smart Client & Web Client: Form Scripts can access local system resources and make connections to external resources from the client PC.
-IDO Ext Class: Can access all server resources and make connections to external resources from the Utility Server. I've also noticed code here seems to perform faster.
My current mode of thinking is: if this functionality should be called from any Form, stick it in an Extension Class. If it's specific to a Form, stick it on the Form (I'm still not 100% sold on this though lol)
As for any tips/etc:
-Mongoose/CSI supports both VB.NET and C#. Infor appears to favor VB.NET (just look at any Infor FormScript). I'm a C# guy (though know both). I'd pick a language & standardize on it. In my case, all my Form Scripts/Ext Classes are in C#.
-If you don't have a version control system in place, get one set up. I opted for Subversion as Infor allows direct integration in CSI 9. NOTE: CSI integration will only work for the "sa" account unless you have a Developer License(s). I would have it set up at least for your coding in Visual Studio, but I would also recommend you turn on Form Control as well. It's definitely a policy/style change, so don't plan on just turning it on.
-I've been using the IDO Extrension Classes to add "missing" (read actually missing or I had no idea where it was in Mongoose) functionality to CSI. I've created library IDO's to hold specific functionality (printing, math, etc.). It helps to centralize code rather than copy/paste code everywhere.
So; that's my $0.02 before my morning coffee. :)
In reply to TimBoyden:
In reply to Stephen Cena:
I agree with the comments above.
If you are looking to port your work to the cloud one day then in Configuration Manager > Configurations > Edit in the Code security section you need to check the boxes which set the WebClient scripts to run in partial trust, and the IDO Extension classes to run in partial trust (Smart client scripts can run without partial trust, they only run on the client machine).
This denies access to reflection and the local file system (amongst other things) which is not permitted in the multi-tenant cloud. It can be a pain to work around this at first especially if you have legacy code to port, or 3rd party libraries which rely on reflection. Starting development with the system locked down avoids surprises later.
There is a usability benefit to IDO methods (custom assembly) code, despite the fact that it can be more difficult to debug, it is possible to reference and use 3rd party DLLs which are also imported into the custom assemblies IDO, these are not accessible in form or global scripts.
Keeping business logic (validation/calculations/triggers) to the IDO/AES layer means it also works in the mid-tier so you get the same behaviour from API's as you do from forms. If you put all your logic/validation in forms and global scripts then the API can become a back door to creating invalid data making it more effort to consume them later.
Last but not least every IDO and its methods can be exposed via the REST API's.
if you create an IDO method (list or scalar) a user which is granted explicit access to the IDO can consume it from the REST API interface.
This could be of special interest to mobile app developers targeting the MT cloud. Using OAuth SSO through ION API gets you to the Mongoose (and other) REST API endpoints making it is easy to consume the business logic developed against an IDO in a connected app.
In reply to Lee Flaherty:
In reply to Dustin Mitchell:
I think I have shared these before but it is relevant to this discussion. There are a couple of youtube channels which are worth looking at.
This is an old youtube channel which the InforOS team have moved away from however it has a lot of material which despite being a bit dated it still relevant. The Mongoose101 video series is effectively ".NET coding in Mongoose 101" The How-To and developer demos are a mixed back of various tips and tricks which you can use some are coding, but the best are the ones which demonstrate how you can use low/no code and use the framework.
This is the newer channel which the Mongoose Enablement team moved to when they became the InforOS enablement team, it has a lot of Mongoose content but is designed to demonstrate the entire InforOS ecosystem when it's fully integrated in the cloud, or on-premise.