Best way to track changes to Impresario for customization compatibility?

Nick,

This is a great question and I’m eager to hear what others are doing.

I rely on a few things to keep track of customizations:

·         An Access database that links all Infomaker reports, SSRS reports, and custom objects, as well as what canned object (if any) the custom object is based off of. I also use this database to track when I make a change to custom objects. (I’m coding by myself here, so this approach works for me, and while Access isn’t perfect, it’s easy to create quick forms and reports for documentation purposes.)

·         I use a homegrown version of sp_findtext to check for dependent objects when making any changes in the database. I believe it’s in the shared reports section on TASK, but I also uploaded the most recent version to my profile on TN.com. (I love this script – it weeds out commented text, so only objects that are really referenced are returned, and I recently added the ability to query report definitions, T_KEYWORD, and TR_QUERY_ELEMENT among other Tess tables in case the object I’m searching for is referenced there.)

·         During upgrade testing, I go through the release notes spreadsheet and database update results and look for any functionality that my custom objects either depend on or are based on, and then change them accordingly.

This method works well, although it’s a pretty involved process. The only part I have yet to handle is finding a way to query Infomaker reports that use scripts rather than stored procedures to see what object dependencies they have. I am trying to move our code away from Infomaker little by little, or at least move all scripts into stored procedures, but that’s a low priority project. (If it ain’t broke…)

~Katie

From: Tessitura Technical Forum [mailto:forums-technical@tessituranetwork.com] On Behalf Of Nick Reilingh
Sent: Friday, January 08, 2016 3:53 PM
To: Catherine Lachance-Duffy
Subject: [Tessitura Technical Forum] Best way to track changes to Impresario for customization compatibility?

Wondering what best practices are from the community for the following:

We all have lots of customizations on our impresario databases -- local tables, utilities, reports, etc. On the database level, our "API" is effectively just all of the built-in impresario tables, functions, and stored procedures. But we don't really have the luxury of the kind of documentation and change tracking that we would expect from a traditional API like REST, at least to my knowledge.

So the trouble comes when it is time to upgrade impresario, and we need to determine if our customizations will need to be updated to accommodate any changes in the upgrade. This is the step that I am wondering about.

Are people running automated unit tests on their customizations? Does this solve the problem?

What I have in my mind as an ideal case is where each of my customizations is documented as to which impresario objects it relies on, and then for any given database update, we could instantly see if any of those required objects have been affected. I've recently spent a lot of time building out documentation for my own customizations, so I now have the first part of this complete, but I am still trying to figure out the best way to track changes to specific impresario objects. To my knowledge, nothing to this effect is being published by the network. (But I'm happy to be proven wrong on this!) Of course, the declarative nature of T-SQL is that the code itself is somewhat self-documenting, so my current thinking/strategy for solving this basically amounts to generating scripts for the entire impresario database from one version to the next and then tracking those scripts in a git repository (in lieu of the Network publishing the same). Theoretically, one should then be able to do some command-line git magic to all at once figure out if any of the relied-upon objects have been altered for the entirety of my org's customizations, making the validation of those customizations for upgrades much more direct and effective.

But I'm still a noob both at PowerShell and command-line Git, so this is slow going at present. Wondering what other ideas people have come up with to address this problem, or if anyone shares this line of thinking.

This message was sent automatically to you by www.tessituranetwork.com because you subscribed to the Tessitura Technical Forum. You may reply to this message to post to the Technical forum or visit the site to search, read and post to the forums. In the interest of keeping the forum posts from becoming cluttered, we encourage you to delete previous message text from your reply before sending. Thank you!

Nick,

This is a great question and I’m eager to hear what others are doing.

I rely on a few things to keep track of customizations:

·         An Access database that links all Infomaker reports, SSRS reports, and custom objects, as well as what canned object (if any) the custom object is based off of. I also use this database to track when I make a change to custom objects. (I’m coding by myself here, so this approach works for me, and while Access isn’t perfect, it’s easy to create quick forms and reports for documentation purposes.)

·         I use a homegrown version of sp_findtext to check for dependent objects when making any changes in the database. I believe it’s in the shared reports section on TASK, but I also uploaded the most recent version to my profile on TN.com. (I love this script – it weeds out commented text, so only objects that are really referenced are returned, and I recently added the ability to query report definitions, T_KEYWORD, and TR_QUERY_ELEMENT among other Tess tables in case the object I’m searching for is referenced there.)

·         During upgrade testing, I go through the release notes spreadsheet and database update results and look for any functionality that my custom objects either depend on or are based on, and then change them accordingly.

This method works well, although it’s a pretty involved process. The only part I have yet to handle is finding a way to query Infomaker reports that use scripts rather than stored procedures to see what object dependencies they have. I am trying to move our code away from Infomaker little by little, or at least move all scripts into stored procedures, but that’s a low priority project. (If it ain’t broke…)

~Katie

From: Tessitura Technical Forum [mailto:forums-technical@tessituranetwork.com] On Behalf Of Nick Reilingh
Sent: Friday, January 08, 2016 3:53 PM
To: Catherine Lachance-Duffy
Subject: [Tessitura Technical Forum] Best way to track changes to Impresario for customization compatibility?

Wondering what best practices are from the community for the following:

We all have lots of customizations on our impresario databases -- local tables, utilities, reports, etc. On the database level, our "API" is effectively just all of the built-in impresario tables, functions, and stored procedures. But we don't really have the luxury of the kind of documentation and change tracking that we would expect from a traditional API like REST, at least to my knowledge.

So the trouble comes when it is time to upgrade impresario, and we need to determine if our customizations will need to be updated to accommodate any changes in the upgrade. This is the step that I am wondering about.

Are people running automated unit tests on their customizations? Does this solve the problem?

What I have in my mind as an ideal case is where each of my customizations is documented as to which impresario objects it relies on, and then for any given database update, we could instantly see if any of those required objects have been affected. I've recently spent a lot of time building out documentation for my own customizations, so I now have the first part of this complete, but I am still trying to figure out the best way to track changes to specific impresario objects. To my knowledge, nothing to this effect is being published by the network. (But I'm happy to be proven wrong on this!) Of course, the declarative nature of T-SQL is that the code itself is somewhat self-documenting, so my current thinking/strategy for solving this basically amounts to generating scripts for the entire impresario database from one version to the next and then tracking those scripts in a git repository (in lieu of the Network publishing the same). Theoretically, one should then be able to do some command-line git magic to all at once figure out if any of the relied-upon objects have been altered for the entirety of my org's customizations, making the validation of those customizations for upgrades much more direct and effective.

But I'm still a noob both at PowerShell and command-line Git, so this is slow going at present. Wondering what other ideas people have come up with to address this problem, or if anyone shares this line of thinking.

This message was sent automatically to you by www.tessituranetwork.com because you subscribed to the Tessitura Technical Forum. You may reply to this message to post to the Technical forum or visit the site to search, read and post to the forums. In the interest of keeping the forum posts from becoming cluttered, we encourage you to delete previous message text from your reply before sending. Thank you!