It can be overwhelming for behavioral health organizations running the Netsmart myAvatar to consider leveraging ScriptLink to extend its capabilities. Perhaps even more so for those who are utilizing it when it is suggested, as I did a month ago, that there are opportunities to improve. Experience, time, and cost can be significant barriers regardless of desire. These are the barriers that I hope we as a community can help each other overcome.
In February 2020, I will begin releasing a number of free resources to help you and your organization overcome these barriers and implement the recommendations I made last month. These include a NuGet package to help accelerate the development of ScriptLink solutions, sample code demonstrating techniques to reduce errors and time to release, and articles describing how to create ScriptLink-compatible solutions.
Initially, these resources will be based on .NET and C#, but I will be adding Visual Basic examples in the near future. I am also hoping to add other languages and technologies down the road. I am interested in suggestions on which language you would like to see next.
AvatarScriptLink.NET (on NuGet as RarelySimple.AvatarScriptLink) is a tool for managing and manipulating the OptionObjects received from myAvatar. It simplifies the most common tasks for a ScriptLink developer:
- Getting and setting FieldValues.
- Setting FieldObjects as required or optional.
- Enabling and disabling FieldObjects.
- Creating the OptionObject for return.
- Setting ErrorCode and Message.
This NuGet package will work with .NET projects written in C# as well as Visual Basic. It will also work with projects built on .NET Framework v.4.6.1 or higher. It is compatible with .NET Core v.2.0 and higher which could be valuable if ScriptLink migrates to REST in the future. Most importantly, it is free to use with your ScriptLink projects.
For those who have been following my work for a while this will look very familiar. While working for Rebekah Children’s Services, I created a similar solution called ScriptLinkStandard. Although it was in production for Rebekah the tool did not reach release publicly. (I do not know at this time if and when Rebekah will resume development and support of ScriptLinkStandard.)
With AvatarScriptLink.NET, I have created a new tool that is mostly compatible ScriptLinkStandard solutions. The Objects have been completely rewritten to support future enhancements, better support backwards compatibility, and reduce the need for repeated code. The Helpers and other advanced options are notably different, but I attempted to keep the developer experience as close to the ScriptLinkStandard experience as I could.
In a sense, this is the next iteration, the third generation, of an idea I have been exploring since I was first introduced to ScriptLink. The release candidate is available today on NuGet and version 1.0 is expected to release within the next two weeks. If you are interested in testing it out, it is ready for you and I am ready to receive issue reports and pull requests.
It’s one thing to read about Design Patterns, best practices, and other recommendations from other developers. It’s another thing to get to see examples of what that looks like in a similar environment. I recognize that despite my earlier recommendations it can be difficult to envision what that may look like.
Let’s briefly review the recommendations I previously made.
- Use a Code Repository
- Use Unit Tests
- Add Logging
- Create Distinct Environments
- Use a Modern Deployment Model
To help see what a ScriptLink-compatible solution could look like that implements these suggestions, I have created a demo solution and made it available for reference on GitHub. The final two recommendations are not included in the sample project.
I recognize that there are many solutions for these recommendations and the ones I present may not be ideal for your environment. However, my hope is that these examples will help you implement these ideas in whatever manner you choose to do so. Here’s how the demo solution achieves these goals.
Recommendation #1: Use a Code Repository
The demo solution is available on GitHub as a public repository. The solution itself is managed and share through this repository. You can see the changes (commits) that I make to the solution over time. As a public repository it is also available for open source collaboration. Whether you choose to use Github, Azure DevOps, or other solution, I strongly recommend you use one.
Recommendation #2: Use Unit Tests
Unit Tests are a fundamental part of a Test-Driven Development strategy. You will find a Unit Test project included in this sample solution. There are 17 different unit tests at the time of writing demonstrating how to test both the selection of the scripts/commands to run and the commands themselves. The solution design also demonstrates how you can design your code to mock the use of ODBC, external web services, and sending emails. This sample uses MSTest v.2 for the unit tests, however there are other popular options, including NUnit and xUnit.
Recommendation #3: Add Logging
The sample project also uses NLog to provide logging throughout the web application. Each command has logging configured such as this one demonstrating an ODBC call. I even include a sample configuration of the logging to demonstrate several of the customization options, such as archiving and filtering.
Starting tomorrow, I will begin a weekly series of blog posts on Getting Started with ScriptLink and .NET. The series will not use AvatarScriptLink.NET at the beginning so that it will have greater relevance to existing implementations. However, later in the series, AvatarScriptLink.NET will be incorporated into various how to articles. I hope you will find these articles helpful.
Are you interested? What do you think? Are there features you would like to see added to AvatarScriptLink.NET? What recommendations do you have for building stronger ScriptLink-compatible solutions?
Want to get involved? You can test out the NuGet package and report any issues today. Have an optimization for the NuGet package or the sample code? Submit a pull request. Your contributions are welcome!