Rarely Simple
It can be easy for developers when working alone to overlook using a code repository. Especially, if like me, they started out just hacking things together to get a task done quickly. This impulse to just check a task off of our list can motivate us to overlook tasks like testing and checking in changes. It may cost a little extra time up front, but it will save you a lot of time later when things go awry.
One of the decisions we have to make when designing our ScriptLink solutions is “how many endpoints (web services) do we want to support?” If we do one endpoint per action then we can end up with dozens if not hundreds of different WSDLs to import and manage. A centralized “controller” means one endpoint to send every request through.
I recommend the latter design if for only one reason. One endpoint makes it easier to redirect your testing myAvatar server (“UAT”) to your testing ScriptLink endpoint. This is especially important after your routine LIVE-to-UAT copy. This means one WSDL to import. It also means there’s a higher likelihood of creating and maintaining a test ScriptLink server avoiding testing in production.
For this design to work we need a way to modify the behavior of our endpoint based on the specific request. Responding “Hello, World!” will be of little use on most forms. Last week, we created a command to run when the API is called. Today, we are going to create a command selector that choose which command to run based on the parameter provided.
In my previous articles, we setup SoapUI and Postman to test the responses to our submissions. While this is an important testing method, it is time consuming and can be difficult to test all the various scenarios. This where Unit Testing comes in. With Unit Tests we can test our code for regressions in seconds (or milliseconds) and as we write our code.
Unfortunately, the design we have followed so far does not support Unit Testing, so we will have to make some changes. The best practice is to write your test, then write your code (make your code changes). So that is what we are going to do.
Last week, we setup our SOAP testing using SoapUI. This provides us a way to see how our API responds to various OptionObject2015 configurations. There is another tool that can be used called Postman. Depending on your context you may prefer this tool over SoapUI. This week, we will walk through the same process using Postman instead.
When we left off, we had created our first Hello World ScriptLink API in .NET using C# and Visual Basic. If we created them correctly, the we should be able to call the RunScript method with the HelloWorld parameter and receive an Error Code 3 with the ErrorMsg “Hello, World!” Let’s test that.
Welcome back to my series on getting started with myAvatar ScriptLink. Today, we are looking at testing. As tempting as it may be. We should not test our ScriptLink APIs in production. We want to test our code before it impacts the users. In our first test, we will set up SoapUI to send a request to our development environment and verify the response.
When we left off, we had created our first Hello World ScriptLink API in .NET using C# and Visual Basic. If we created them correctly, the we should be able to call the RunScript method with the HelloWorld parameter and receive an Error Code 3 with the ErrorMsg “Hello, World!” Let’s test that.
Using ScriptLink with your Netsmart myAvatar implementation does not require that you use .NET or even C#. That is just what I primarily use. In this article we will be revisiting the creation of our first ScriptLink API in .NET, but this time using Visual Basic (VB). If you are more comfortable and proficient with VB, then you can stick with it.
Most of my IT career has involved the implementation, maintenance, and configuration of electronic health record (EHR) solutions in the behavioral health space. Much of this work has been the usual suspects of security, report writing, end user support, and process design. However, it has also involved a health dose of extending the EHR to add additional features and capabilities. The Netsmart myAvatar EHR solution includes a variety of options for extending the solution.
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.
I have been working with Netsmart myAvatar and its ScriptLink feature for many years now. ScriptLink enables organizations to extend the functionality of most forms in the medical record. As with any extension feature, there are significant opportunities to improve or hinder the user’s experience and the overall solution. This means that a robust, mature solution can enhance the gains and minimize the risks.
Rarely Simple 