In today’s post we're providing a sample application skeleton that may be used to play with External Activator, as well as serve as a base for writing custom activated applications.
A file with source code of the application is attached to this post and you can get it by clicking here.
The sample assumes a usage scenario where the activated application is used to offload some CPU-intensive computation from Sql Server. Whenever there’s some work to be done, Sql Server creates a conversation and sends a RequestMessage on it. The message contains some application-specific binary payload. The activated application receives such message, performs the computation and sends back a ResponseMessage containing the results of the computation. At this point Sql Server may decide to end the conversation or keep sending more RequestMessages on the same conversation. Upon receiving error or end conversation messages, the activated application will end its end of the conversation (and write an entry to Windows Event Log in case of error message). For the purpose of this sample, the “CPU-intensive computation” is just calculating an MD5 hash of the incoming payload.
Note that some users may prefer to insert the result directly into database table rather than sending a response message. However, this sample chooses a response message approach, since it provides better decoupling between the activated application and database schema.
The application is somewhat generic in the sense that it is passed the location of the queue it should read messages from as command line arguments. That way, it may be compiled once and used for servicing more than just single application queue. In order to make it work, you need to make sure the first 4 command line arguments External Activator passes to the app are:
- The Sql Server instance to connect to.
- The name of the database where the application queue is located.
- The name of the schema where the application queue is located.
- The name of the application queue.
Luckily, External Activator is able to generate these arguments based on the contents of the event notification message received (the Sql-generated message that triggers launching the user app). All you need to do is to configure the LaunchInfo section of the EAService.config file like this:
<LaunchInfo>
<ImagePath>c:\test\MessageProcessingApplication.exe</ImagePath>
<CmdLineArgs> %sqlserver% %database% %schema% %queue% </CmdLineArgs>
<WorkDir>c:\test</WorkDir>
</LaunchInfo>
One more thing: The example app requires a specific Windows Event Log source to exist and we didn’t want to force you to play with the code using admin privileges. Therefore, prior to running the main app, the event source needs to be explicitly created. For your convenience, the code includes helpers to create and destroy the event log source. In order to create it, simply execute the app with CreateLogSource command line argument (for deleting the source, use DeleteLogSource). You need to do that as administrator (elevated).
That's it for now; next time we’ll provide a step-by-step guide how to configure External Activator so that this simple app may be tested, as well as how to troubleshoot any issues.