Best Practices

[scott-malyon]

Hi There,

I have been investigating the possibilities of the CallAssembly node and have some questions about best practices:

1. Exception handling I have seen several approaches to this in the examples, which is preferred: a. Catch and log to file from the assembly b. Catch and return a message on field -1 c. Don't catch and let them bubble up

2. Non-Framework Dependencies I notice the the Twilio example references several 3rd party assemblies but the documentation says to put assemblies in the engine folder: a. Should they be sub-foldered to prevent versioning issues? b. Can they be placed anywhere outside of the engine folder?

3. What maximum target framework should be used?

4. What is the format for a multi-value field when returning the dictionary?

Regards, Scott

[bbanet]

1. Exception handling - Avoid the no catch strategy. It will be very difficult to troubleshoot errors post deployment if you don't handle. We post messages to a field in a lot of scenarios as its the best way to reflect problems directly to the end user without having to expose them to the batch management interfaces. Writing to a log is file or sending messages to the Windows event log is the best way to handle verbose messaging with stack traces. Remember that the engine is multi-threaded so their is the potential for simultaneous writes, so any logging scenario would need to account for this. Windows event logging would be the simplest approach for this reason.

2. If you are using assemblies that may conflict with core Square 9 assemblies, you would want to attempt to leverage assemblies of the same version we are using. Rule of thumb should be never overwrite anything in our bin folders. You can sub-folder, but this can cause problems because your authored assembly is loaded by the runtime in memory, not from a file location.

3. Current shipping versions of the GlobalAction engine are v4.5. Since our engine is the caller, you would not be able to exceed its framework version. The next major release of GlobalAction will step the version to 4.7.2.

4. At present, MV fields are not sent in the dictionary in either direction. If you needed to access MV fields, you would need to go at the database directly, or hook into the Square9API endpoints for a particular document.

[scott-malyon]

Thanks for the response, I have a couple of follow-ups:

1. Do you create a specific process field for user friendly error responses and also add validation to the workflow to prevent workflow completion?

2. Do your products create an event source in the event log I can utilise? If so which log/sources do you create. I'd like to avoid creating one on the fly as it requires elevation. Or during installation as it requires the user to perform additional steps. I did have a look through the application log but could only see Square9 Licencing manager and Mail engine

Yes I found out about the Square9 assemblies all being loaded by listing them all. I was having trouble loading NewtonSoft.Json V11, even with an binding redirect. I solved it in the end by referencing the version you are using. Which is fine but did stop me using a another library that had a dependency on V11, but it wasn't a big problem once I knew.

[bbanet]

1. Yes, this is an appropriate pattern.
2. There are a couple random ones as you point out, but there is nothing beyond that, and those wouldn't necessarily exist in all environments. If you are concerned about elevation, the safest bet would likely be to create the source at setup time.