Daily I'm going to create a number of Tessitura Accounts based on information we are gathering at several points around the building.
I have a sense that there are several ways I could automate this:
What are folks having the most success with as an approach for bulk creating accounts? Particularly methods that is robust to Tessitura System Changes over time?
What documentation exists for automating such a process?
Thanks for any help you are able to share.
--Tom
Hi Tom,
I don't know if this helps, but we tend to take the approach of utilizing the existing import stored procedures when we automate things. That way, we're still taking advantage of much of the utility Tessitura built while adding the ability to automate.
For example, I have a "mostly" automated ("mostly" only because I still need to refine a few things, not due to any technical limitation) process that pulls donor data from Stripe's API into Tessitura. We are using contribution import; however, rather than running the utility manually, my script populates the import tables (i.e. TW_CONTRIBUTION_IMPORT in this case), performs a few things we wanted to do before the import takes place (primarily related to how duplicate records are identified), then makes calls to the same import stored procedures the utility would call. The end result is automation without reinventing the wheel. A similar approach should work for constituent import as the two utilities are similar and contribution import actually calls constituent import as part of its process. If there is additional data the standard import stored procedures do not handle, you could always handle that with some additional code after the import takes place.
I did consider loading data into the tables directly, but my theory is that this may be more likely to break over time due to changes Tessitura makes behind the scenes whereas the import stored procedures should be updated by Tessitura as they make changes. In the long run, however, I think utilizing the REST services for such purposes is ultimately the best approach and I would imagine we'll see newer versions of these import utilities that leverages services rather than stored procedures. I will hopefully find time to explore that at some point in 2020!
I wish you the best as you work on this and will be curious to learn what you come up with!
Thanks,
David
David Frederick
Thanks for your perspective.
I'm leaning toward the API option from a Python Job that uses the REST API for data insertion. I think I've found the right calls to do that. And I'm thinking about a list and a custom output set element to extract the needed data.The API does not seem to provide the data elements that I need. If that does not work then creating a custom REST call for data might be the next step
The import approach would then work for both data inside the database and any external sources. The approach sits on top of all of the error checking and upgrades protection that the REST API hopefully provides.
However, I'm likely the only person around the museum who knows Python. So support over the longest term might cause some challenges.
Time for a quick and dirty protype.