Using System.AppDomain to share data between Automation Objects - Part 2

In Part 1 I introduced you to the System.AppDomain .NET class a way to share complex types between objects in Application Server (as long as the objects are hosted in the same AppEngine). As an example, I shared a database connection to the Historian Server database (Runtime) through the AppEngine object.

Now, let's take a look at the sample script needed in the other objects to access the shared database connection.

Using System.AppDomain to share data between Automation Objects - Part 1

This one is for advance Application Server users.

When writing complex .NET scripts within automation objects, you might find the need to share information between objects that is not of a standard ArchestrA data type. In other words: if your script is using a .NET type that is not compatible with the data types available for a UDA, how do you share that data between two or more objects in your Galaxy? If you read the title of this post you guessed right: using the .NET System.AppDomain class.

There is one caveat, though. You can only share the data between objects in the same AppEngine.

Note: The AppDomain class provides an isolated environment to execute applications. We are using it as a "trick" to share data within your application, but it's not its real purpose.

In this 2-part article, I will walk you through an example sharing a connection to a SQL Server database. In Part 1 I will show you how to create and make the connection available to the rest of the application. In Part 2 I will show you how to access the connection from a different object.

Sending E-mails from an Automation Object - Part 2

In Part 1 I discussed a script that allows your Galaxy to send e-mails through an SMTP server. The e-mail, while short and simple, was all contained within a single Execute script. This means that every single class used by the script is instantiated and initialized every time the script runs. Also, all the information that the script uses was hardcoded within the script itself.

Let's take advantage of the different execution types, UDAs, and the Declarations section to reshape the script into a better, optimized, and well-structured object. Details after the break.

Sending E-mails from an Automation Object - Part 1

Once in a while I hear people asking how to send e-mails from Application Server. As long as you have access, or rather your Galaxy has access to an SMTP (Simple Mail Transfer Protocol) server, you can configure an object to perform this task using the System.Net.Mail namespace of the Microsoft .NET Framework.

After the break, I'll walk you through a basic script that will send e-mails though Gmail SMTP server. Later, in Part 2, I will describe a better, optimized version of the object and script.

How-To: Use Text-to-Speech in an ArchestrA Symbol

Microsoft included their speech engine (SAPI, a COM-based API) in Windows Server 2000 and later versions of their operating system; a managed code version of the API was introduced with the .NET Framework 3.0. The ArchestrA scripting engine, QuickScript.NET, allows calls to both COM and .NET libraries; this and Application Server's capability to import COM and .NET files into the Galaxy makes it easy for you to use Microsoft's speech engine for Text-to-Speech (TTS) and other speech-related functions.

You can use QuickScript.NET within an automation object or in an ArchestrA Symbol. While adding TTS capabilities to an automation object is possible, it might not be a good idea since most likely the object will be deployed to a server-type node with no user physically located at the station. A better approach is to add TTS capabilities to an ArchestrA Symbol since the graphic can be made available to a user through their InTouch application.

For this article, we will focus on the .NET version of the speech engine: System.Speech.Synthesis. This engine allows access to the speech synthesis engine which provides the TTS capabilities, including the conversion of text to speech (even from and to a file) and manipulation of the voice parameters (like speed and volume).

Depending on your operating system, you might have access to only one voice. You can find other voices online (not necessarily for free) that are compatible with the Microsoft speech engine. The API allows you to query the characteristics of all the voices available, like name, gender, and age.