RatchetSoft Wins 2012 Coder Royale

Just in case you missed it, RatchetSoft was selected as the winner of the 2012 ICUC Coder Royale Contest. Our Ratchet-X-based click-to-call solution enables users to initiate calls placed through inContact's cloud-based call center infrastructure from any application without requiring changes to those applications. Click here to see the winning entry video.

Special thanks to George Weihs and the development team that worked on this project. Congratulations!

Technique: Integrating Applications On A Remote Desktop

In most cases, Ratchet-X works fine when used to integrate applications that are running on a remote desktop like Citrix's XenApp, VMWare's ThinApp or Microsoft's App-V. In these cases, it’s common to deploy Ratchet-X itself on that remote desktop along with the target application to be integrated. To the end user, he would never even know that either application is deployed remotely. The Ratchet-X Commander icon still appears in its usual spot in his windows system tray. Interacting with it seems to be the exact same experience as if it were installed locally. However, it’s important to remember that Ratchet-X is deployed remotely and only has access to other apps running on the same remote desktop. Applications running natively on the actual desktop cannot be accessed by the remotely deployed Ratchet-X Commander or visa versa. Or can they?

We’ve been using a technique that allows us to bridge this gap. For example, imagine there's a line of business application that is deployed as a Citrix XenApp. We want to place a magic button on that XenApp when the user navigates the application into a certain state (e.g. Invoice Summary Window). We define a RegWin for that window and save it into an appspace that we register with Ratchet-X running on the remote desktop. That method handles the screen recognition and appearance of magic button. When the magic button is clicked, Ratchet-X runs the action on the remote desktop that needs to (somehow), load an application on the actual workstation and do some navigation (we call this the Jump2 pattern). Now this is  where the problem lies. Although we currently we have no direct way to communicate between these two desktops (though we'll soon have an elegant solution that universally addresses this problem across all remoting desktop solutions without being vendor specific), we do have a pretty clever integration technique that can be used as a stand in. The technique involves the passing of this data from the remote desktop to the local desktop using a built-in feature of our Action API.  

When called, the method WaitForScreenDataTransfer, found on the ActionContext object, loads a window on the desktop which displays text data you pass it. This window loads offscreen (not visible) or center screen (visible), and simply waits until the user closes it (click window close button). This proves to be an effective way to transfer some limited data (up to 4K), from the remote desktop to the actual windows desktop. It works because the remoting software (XenApp, etc..) faithfully copies the titlebar text over to its virtual window running on the local desktop. Now this window titlebar text data can be seen from Ratchet-X running on the local desktop. We simply need a RegWin on the local desktop's Ratchet-X which we can register as an "Auto-Run" and associate it with a local action. That local action simply reads the titlebar text from the RegWin that auto-ran and goes about its business as usual - accessing any resources it needs on the local desktop.  

To summarize, here are the high points of this integration:

From the User’s Perspective	Behind the Scenes
User loads his accounting application and navigates to the Invoice Summary window and the magic button displays on the titlebar.	Ratchet-X, running on the remote machine detects a known RegWin and displays the magic button.
User clicks the magic button.	Ratchet-X running on the remote machine starts to run an action on the remote desktop which calls WaitForScreenDataTransfer and passes in an invoice number. This displays a window (virtualized and available on the local desktop but not visually seen because its loaded off-screen. Then, Ratchet-X running on the local machine detects the ScreenDataTransfer RegWin and auto-runs another action on the local desktop. That action reads the invoice number from the ScreenDataTransfer RegWin and loads a local document management executable to display the appropriate document on the user's local desktop.
User sees invoice document appear.

If you want to try this yourself, take a look at a sample appspace that ships with Ratchet-X demonstrating this technique. In Sample Appspaces, register the RatchetX.ScreenDataTransfer appspace. This appspace contains a RegWin that matches the window created by the ScreenDataTransfer window. In the field, you’ll need to make your own RegWin that matches the window as displayed by your remoting provider.