Testing Your ScriptLink API with Postman

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.

Advertisement

Testing Your ScriptLink API with SoapUI

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.

My 2020 myAvatar ScriptLink Wishlist

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.