Results Processing and Handling Network Disruptions

[wterry]

Hello TestStand Community,

I am working on standing up a TestStand based testing capability for my organization, and was wondering if anyone has advice on how to handle network outages with TestStand. Our current approach to results processing is to send all results to a remote database, however our infrastructure is notoriously bad, and we experience frequent network outages. 

My initial thought was to setup offline result processing in parallel with database result processing, and some callback to handle errors when connecting to the database. However, there aren't any pre-condition options for offline result processing like there are with database result processing. I'm assuming that means that I would need to handle duplicate entries when the offline results are processed, and I would prefer not to have to do that since the majority of offline results would be duplicates.

Does any know of a way to enable and disable result processing outputs dynamically? Are there side-effects to enabling/disabling result processing outputs dynamically? Does anyone have a more elegant solution to handling interruptions to database logging, something that would require less leg-work?

I am using TestStand 2017.

Thanks

[wterry]

It just occurred to me; even if I programatically enabled/disabled result processing outputs as described in this KnowledgeBase Article I still need a way to handle failures to log to the database. I'm reasonably confident that I can figure out how to react to database issues. Now, can anyone tell me if there is a way to guarantee which logging output is processed first? i.e. I need to preserve results with the offline processing output if and only if logging to the database fails, so I need to wait to generate offline results until after I have attempted to log results to the database.

[~jiggawax~]

It goes in the order from top to bottom that they show up in the configuration.

[wterry]

Awesome, that makes things a little easier. Thanks, Jigg.

For those interested in being able to handle network interruptions I will, hopefully, post my solution. It might be a few weeks before I can tackle it though.