Best practices for Scripting

While developing scripts for the platform, there are a series of practices that save development time and guarantee more quality in your produced scripts. This information is also in the platform's manual, but we reproduce it below:

• While testing/developing your script, use the platform's Scripting tool to test in Visual Studio. This avoids the complexity of having to repeat the operations on the platform that will trigger the script, and you can still test with real data;

• After it is developed, however, it is important to ensure that it will also function under real (platform) conditions – some things may not be the same between the two scenarios, such as any referenced external DLLs.

• When interacting with external systems, ensure that if a method returns a dynamic object, you cast it to the correct type before proceeding, to avoid obtaining “Cannot convert object to string”-type errors;

• Your scripts should be designed considering the possible failure scenarios. See the following case: you integrate a document into an external system, but the external system crashes before returning the response to the platform that it was successfully integrated. This will lead to an inconsistency when you integrate again, potentially causing a duplicate document.

To avoid this, ensure that there is always a field in the external system identifying the platform’s document and vice-versa, and that you perform checks on these fields when running the script.

• Ensure your scripts are developed in the UTF-8 encoding (no BOM);

• Ensure you always close any connections that you open, even in failure scenarios (e.g. an exception should go into a catch that closes any connections that were still open)

• Be pessimistic when dealing with responses from external systems – if the connection fails or the response is not correct, your script should fail gracefully.