Aras Innovator prides itself on being a flexible platform that can be easily customized to fit any of your business needs. Today we'll be covering some general best practices to keep in mind as you begin your journey of customizing Aras Innovator.

Make Changes to the Database (Not the Codetree)

When we want to extend and change how our users interact with Aras Innovator, there are two main ways we can go about it. Let's consider a simple example where we want to add a button to the toolbar of an item's form.

The first way, and in much earlier versions of the only way, is to navigate to wherever we have installed Aras Innovator (we refer to this as the codetree) on our server and make changes directly to the source files that control how item forms are rendered. Making changes this way offers the most flexibility in terms of fine-tuning exactly how you want the UI to look, but it comes with pretty substantial downsides.

• It introduces potential caching issues for users who have an older version of the file cached locally
• Pin-pointing exactly which file needs to be modified is difficult
• Migrating the changes to other instances (like a development or production server) is more cumbersome
• Upgrading to a newer version of is more time-consuming as codetree files are the most likely to change between versions

Instead, it's better to take the second approach whenever possible, and make changes directly inside the database. For our example of wanting to add a new button to the toolbar, we can easily accomplish this in most versions of Aras Innovator 11.0 and every version of Aras Innovator 12.0 by using the Configurable User Interface (CUI). Item toolbars aren't the only place where you can easily add or remove UI elements. Since it's introduction in Aras Innovator 11.0 SP7, many areas of the UI are now rendered and thus are configurable through the CUI data model. If you're interested in customizing your Aras Innovator user interface, we have many blogs that cover CUI and how to make changes to specific areas.

When CUI Won't Cut It

CUI is very powerful in what it allows us to change, but it is also limited to only those areas that are currently supported. Let's say we have an ItemType that we want users to edit by using a completely custom user interface that looks nothing like a standard Aras form. Even in cases like this, it may still be possible to make your changes only to the database.

In a previous blog post, we covered how to build completely custom user interfaces by using HTML inside of an Aras form. The approach covered in that blog post also allows scripting by adding JavaScript methods as Form Events. While you might have to structure your code differently, it is just as powerful as creating HTML and JS files directly in the codetree. We can even use 3rd party JavaScript libraries inside of Innovator methods. If we're using a 3rd party library like jQuery or Bootstrap that supports using a CDN, we still wouldn't need to make any changes to the codetree!

Methods

Besides creating a a new ItemType, writing a new Method is one of the first pieces of customization that most people will make to their Aras Innovator instance. These custom Methods will obviously be stored in the database, but there are some additional best practices to keep in mind. 

Keep Methods Small

The easiest thing to implement when we start developing is to enforce some soft limit on how many lines of code we want our Methods to be. Developers have different personal thresholds that are anywhere from 15-50 lines of code, but the main thing we're trying to avoid is one very bloated Method that controls everything. While it's easy to enforce a code limit at the start, it's very difficult to go back and break up a single Method that is thousands of lines long. 

Use Server Methods Where Possible

Another best practice we can put into place early is to have a clear distinction of what should be done client-side via a JavaScript Method and what should be done server-side via a C# or VB Method. Most of the Methods that I end up writing are to manipulate Item data in the database. While it's possible to use the JavaScript API to send AML to the database, I've found it's better to do item processing on the server whenever possible. This approach ends up being more flexible if needs change in the future. If you use a JavaScript Method, that code can only ever be used inside of the Innovator UI. If at any point later on, we create an external application like a PWA that could communicate with our Aras Innovator instance, we would need to duplicate that functionality. A single C# Method, however, could be called by both applications and would require maintenance of only a single source of code.

Use Asynchronous JavaScript Code

Lastly, we should try to use asynchronous JavaScript code whenever possible. If we follow the best practice above, we'll often times need to call a Server Method from our client-side JavaScript Methods. Depending on the latency of our network, just getting the request to the server might take a second or two let alone the additional time needed for our Server Method to actually compute. With a straightforward approach, we would end up in a situation where the client-side UI is locked for the user with no form of feedback. By using asynchronous code, we can achieve a much more user-friendly experience.

The sample code below demonstrates how to display a spinner to the user for calls that we expect might have a long run time. 

Using this approach, the user will see a spinner for as long as the server call takes to run. This will still prevent our user from doing additional work, but they will at least have visual confirmation that the UI hasn't just hung on them. If we expect our call might take an extremely long time, we could rewrite our code to remove the await call and to maybe throw up a confirmation dialog after the server call returns. This would not lock the UI, so our user would be able to continue performing work while our long-running request runs completely in the background.

If you're unfamiliar with asynchronous JavaScript programming entirely, I'd recommend checking out this external resource which I've found very helpful.

Conclusion

Developing for Aras Innovator requires some domain-specific knowledge, but many software development best practices can still be applied to improve the overall performance, maintainability, and usability of the platform. As with any development best practices, the best time to start thinking about them is before any code has been written or customizations have been made. Please comment below with any best practices or design guides you use for your Aras Innovator instance.