Open UI: Protocol Handler

Getting rid of Active X usage is a priority on Open UI projects, because it allows Siebel customers to embrace more modern browsers, and remain compliant into the future, but one of the last bastions of Active X support in a Siebel Open UI project stems from a requirement to launch executables inside an internal domain.

Launching a program on the users local machine, requires browser script code similar to the following to be implemented.

var sCmd = "notepad.exe text.txt";
var shell = new ActiveXObject("WScript.Shell") ;
shell.Exec(sCmd);

As part of an Open UI upgrade review to remove browser script, I recommended to a Siebel customer that they implement a custom protocol handler to get around the above dependence on Active X.

Protocol handlers are cross platform, and are supported by the major browsers. Although the term protocol handler is obscure amongst general users, its usage is quite prolithic. Here are some common examples of protocols which are handled by browsers

http://
https://
ftp://

The above protocols are trapped and handled internally by the browser, while other protocols are passed down to the OS to be handled by the default program.

mailto://
itmss://

When mailto:// is typed in to the browser address bar, it launches the default program which is registered to handle emails. Apple users will also recognize the second protocol itmss://, as it is used to launch iTunes, the subtle suggestion here is, we could use the same technique to launch any executable.

Each platform has its own method of implementing protocol handlers, so if you are lucky enough to support mac users on Siebel, you’ll need to look into the appropriate vendor documentation. The MSDN reference provides a good digest for those wanting to implement protocol handlers in windows.

https://msdn.microsoft.com/en-us/library/aa767914(v=vs.85).aspx

To implement a handler for a new protocol named jle://, a simple reg file can be created and imported to into the registry.

Windows Registry Editor Version 5.00
 
[HKEY_CLASSES_ROOT\jle]
@="URL:jle protocol"
"URL Protocol"=""
 
[HKEY_CLASSES_ROOT\jle\DefaultIcon]
@="C:\Apps\protocol_handler.bat"
 
[HKEY_CLASSES_ROOT\jle\shell]
 
[HKEY_CLASSES_ROOT\jle\shell\open]
 
[HKEY_CLASSES_ROOT\jle\shell\open\command]
@="C:\Apps\protocol_handler.bat" "%1"

Replace “jle” with your own protocol, and substitute the path to “protocol_handler.bat” according to your local path. “protocol_handler.bat” is a test file that can be used debug the arguments, to see what gets passed to the invoked program, but you may want to use something more sophisticated than a batch file.

rem protocol_handler.bat file
@echo off
echo %1
pause

Once thats setup, type the the new protocol + program arguments into the browser address bar and press enter. Here’s a screenshot of the protocol handler in action.

When designing the protocol handler, keep in mind that you may want to implement a lookup system, to maintain the flexibility of invoking different programs, without having to register new protocols.

This approach was used on an Open UI upgrade to negate the dependence on ActiveX in IP2012+. If you are looking to solve similar requirements on your project, it is important to keep the following points in mind.

Pros			Cons
No Active X Works across all browsers, and platforms Does not need elevated privileges Launch only registered programs			Requires desktop deployment Requires non Siebel expertise

SHARE