While developing a workflow project for a customer, I noticed that some machines in the customer environment were using IE9 as the primary browser. I also noticed that my form design worked very poorly in IE9. Because the team I was working with had a bit of control over the business paradigm, I was able to design the form to indicate to the end user that “IE9 is an unsupported browser, please use Chrome or etc etc”. This was fantastic, since I really didn’t want to have to go back and redesign everything to work with IE9.
In this post response by reecardo on Symantec Connect, it’s mentioned that the Get HTTP Request Value component can be configured to return the HTTP_USER_AGENT string. So instead of doing all the work to parse that string reliably, (see this post to find out why this string response is so convoluted), I decided to instead use that time to learn some more C#.
Here’s my run at building a Code (Script) Component that returns usable values containing client browser data.
In order to test this, let’s start with a clean project. Add the components, connected as illustrated below:
- Initialize Data
- Code (Script) Component
- Form Builder
- Hanging Path Trigger
- Exception Trigger
In the Initialize Data component, declare a “Key Value Pair” variable to hold the browser data we want.
On the Form Builder component, add some elements like the Label component and AsciiMergeLabel component to display the browser data.
Now, for the Code (Script) Component.
We aren’t using input variables for this component, so leave Page 1 blank.
Configure the “BrowserResult” key value pair variable as the Result on Page 2.
Enter the following code on Page 3, using C# as the language, and these namespaces:
HttpBrowserCapabilities Prefix = HttpContext.Current.Request.Browser; string bKey = Prefix.Browser.ToString(); string bValue = Prefix.MajorVersion.ToString(); return new KeyValueDataType(bKey,bValue);
While I chose to use “Prefix.Browser” (e.g. “Chrome”) and “Prefix.MajorVersion” (e.g. “39”), other output options are available. See this article for more info.
On Page 4, ignore the tests, as the result will not be satisfactory. The context of this component is expected to be run within a browser, and as such, the test option here will fail.
Click Finish to close.
Test the project in different browsers to see the results.
When compared to my original attempt at parsing the returned string from the Get HTTP Request Value, it should be apparent why I prefer this method.
Original (the Http Get component is using an API to return a translation of the HTTP_USER_AGENT string):
Custom C# component:
So the process has been streamlined a bit, and requires far less effort.