Best practice tips for maintaining an Innovator installation!

Hi Angela,

The first maintenance tip I'd suggest for anyone using a database-centered application like Aras Innovator is take regular backups of your database. How often to do this depends on how much the system is being used, but I'd recommend at least weekly if not daily backups. Accidents happen, servers crash, and knowing you have a backup will give peace of mind that you won't lose too much work. I'd also especially recommend taking a backup before any major configuration changes happen like importing a community project.

Besides that, there are a number of resources available online for maintaining and refactoring code bases. If you make heavy use of custom Methods, it'd be a good idea to occasionally go through the code base and refactor where appropriate. In terms of performance and efficiency, it'd be worthwhile to make sure all Methods are following the best practices by limiting the amount of calls to the server and limiting the amount of data returned. Some of these refactoring concepts can also be applied more generally to other items outside of Methods or code.

One suggestion when refactoring is to trim "dead code" that either doesn't affect the result of a program or was once used and has now been made obsolete. This concept can be applied to some code inside of a method, an entire Method, or even other items like Properties, Identities, Permissions, or whole ItemTypes. Perhaps a Property existed to store some data that's now being tracked another way or maybe a Group Identity was created for a temporary purpose and was never deleted afterwards. This kind of trimming should not be done lightly, but it can make maintenance easier since it limits the amount of items you need to look through. This is one example of a major configuration change that would warrant creating a backup before implementing. :) 

Another refactoring tip is to break up large chunks of code into smaller functions. Similarly, this concept can be applied to ItemTypes. If you have a single ItemType with 100 properties, it might be worth considering if it makes sense to split that up into several different ItemTypes.

To avoid too long of a response, I'll stop there. This is a great question though! I'm excited to see what other responses this gets. 

Chris

Christopher Gillis

Aras Labs Software Engineer

Hi Chris, 

thanks for this awesome start of this discussion! It's funny that I didn't explicitly list "Backup" on my own list. Because of course it is mandatory and the most important topic.

I like your tips to prevent problems with good design from the start. Many speed problems can be prevented by query design and adding the 'select' attribute. If I would be Aras, I would write this in big red letters at every page of the programmers guide.

Of course, as an Aras employee you don't count if I want to expand the list. I want the community to be more collaborative :-)

Awesome topic, I hope it helps a lot of people avoid mistakes.

Hi Angela,

Interesting topic. Here is my list excluding things that you have already covered

Regular Checks:

1. Weekly or bi weekly a DBA runs profiler on ARAS database to identify possible ways to improve performance. DBA does data base tuning, re indexing if required.

2. As user base increases so is the data and database size. So to improve performance few data heavy reports can be converted from AML to SQL to take advantage of SQL views as a mean of improving performance.

For performance improvement:

1. Normally as functionality is built with multiple sprints there is scope for optimization since many times on same event we create multiple methods during different sprints. So we take up short performance improvement project after delivery of particular module, where idea is

  1.1 Aggregate functions on same events

  1.2 Push code to server side method from client side method as much as possible

  1.3 Follow ARAS tips on performance improvement like using attributes select, doGetItem etc ..

Hi community,

I think it's time to give this discussion another spin.

Chris seemed to be very inspired by this discussion and provided us with an additional blog article with a lot of useful stuff:
https://community.aras.com/b/english/posts/dos-donts-of-designing-applications

Many thanks for this one! But all of you so far forgot one important thing: Documentation!

So here we have the next basic tip: As soon as you implement something new or change default behavior of something write a test case immediately!

Typical examples:

You built a custom ItemType with a LifeCycle, Workflow and a couple of Methods. Write down a test case so Aras update team can later reproduce how the whole bunch shall work. Don´t make one big generic test cases that nobody can follow ("My custom change management process shall work"). Better make a lot of steps that exactly describe what to do and what behavior to expect. E.g. "Login as admin. Go to TOC->MyCustomChange. Select a CustomChange item. Click on custom Action xy, confirm that yz happens....".

Avoid to customize existing Methods. Make a custom copy whenever it´s possible. When it is not possible to work with a copy, always add some comments that indicates that "you" have customized this and also why. And of course - write a test case that describes the changed behavior.

Most important is the documentation of codetree changes, cause they are often hard to detect for Aras update team. Describe the file you have changed a and add a test case that shows the effect of the codetree change, so Aras is able to reproduce it. Not only Aras, you yourself have some benefit when you write down these details, cause at a certain point you cannot remember anything anymore.

Excellent points, Angela! My hope was that the blog post wouldn't be a definitive guide but would demonstrate that any good software design principle can be applied in the context of Innovator. 

You bring up an excellent Innovator-specific tip as well in terms of making a custom copy of any existing Method. In the event that the Method changes in a newer service pack, it not only makes it easier to upgrade, but also to compare with your custom code to find what the updates were.

For similar reasons, I'd also apply this same tip to codetree changes as well. If you want to make an update to a codetree file, instead create a copy of the file with the same name and rename the original file to filename_old or filename_original. In addition to making it more clear where changes were made, it also helps to have a clean copy to rollback to just in case something breaks in development or testing. You can see that Labs does this in some of its projects like the TOC Searchbar.

Hi community,

due to a spam message I noticed that this wonderful old discussion still exists. It´s a 3 years old thread but I think the topic is still relevant and important.

So I want to bring the discussion back to live with an additional tip:

Have a disaster recovery plan!

Sample content:

1. What to do when Innovator (or parts of it) don´t work? -> Possible answer: Restart IIS, Check app pools, etc. . IMPORTANT. Describe WHERE to find these kind of settings and which kind of permissions are required, cause not everybody is super familiar with the server. 
2. Where to look when interface/connector xy is down? E.g. when CAD connector doesn´t work, check this and that
3. What do specific commonly known error messages mean?
4. What were issue in the past?
5. ..

So far I never needed the disaster recovery plan in practice. But if people ask what they should do when Aras is down while the admins are on
a booze cruise in the Caribbean Sea - the recovery plan is the answer!

Do you have more useful tips?