• Replies 7 replies
  • Subscribers 26 subscribers
  • Views 24038 views
  • Users 0 members are here
Options
Related

Best practice tips for maintaining an Innovator installation!

AngelaIp

Hi Community,

I want to use this thread to collect maintenance tips regarding Innovator. What is your experience? What do you think is worth to do on a regular basis to ensure long life stability and performance? See it as preventive health check for our Innovator platform, so we can identify upcoming problems before they occur.

Here are some examples. A lot of these task can already be automated:

  • Check if the latest service packs are worth an update
  • Check for active/inactive users
  • Check if file vault has still enough space
  • Check for failed conversion tasks
  • …

Questions:

  • What would would you recommend to check on a regular basis?
  • How do you monitor Innovator, e.g. to find performance consuming events?

Looking forward to hear your ideas! My shown list only shows a small part of my current list. I will share my experience if you share yours (that´s the deal Slight smile )

Best regards
Angela

Parents
  • Offline

    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

Reply
  • Offline

    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

Children
No Data