SupportSoft v6.5 Client Architecture and Customization Guide

SupportSoft v6.5 Client Architecture and Customization Guide
SupportSoft v6.5 Client
Architecture and Customization
Guide
(Updated September 18, 2007 - For Repair Manager v6.5 SP3,
Subscriber Agent v6.5 SP2 and SmartAccess v6.5 SP 1)
Your use of this document is subject to the terms of your license agreement, including without limitation
those sections of your license agreement providing for the protection of the confidential and proprietary
information contained herein.
The information contained in this document is subject to change without notice. SupportSoft makes no
warranty of any kind with regard to this material, including but not limited to the implied warranties of
merchantability and fitness for a particular purpose. SupportSoft shall not be liable for errors contained
herein or for incidental or consequential damages in connection with the furnishing, performance or use of
this material or for the interpretation thereof.
SupportSoft, Resolution Suite, SmartIssue, SmartResult and Nexus are registered trademarks of
SupportSoft, Inc., and all other product names, service names, slogans, and related logos are trademarks
or service marks of SupportSoft in the United States and other countries. All other company, product or
service names referenced herein are used for identification purposes only and may be trademarks of their
respective owners.
The software referenced in this document may be protected by patents: Patent Numbers 5,996,073;
6,158,001; 6,163,859; 6,167,358; 6,266,788; 6,442,684, and 6,754,707.
Copyright © 1997-2007 SupportSoft, Inc. All rights reserved. Photocopying, reproduction, or translation in
any form or into any other language without the prior written consent of SupportSoft, Inc. is forbidden.
SupportSoft, Inc
1900 Seaport Blvd, Redwood City, CA 94063
Phone: (877) 493-2778
Fax: (650) 556-1195
www.supportsoft.com
SupportSoft, Inc.
2
SupportSoft Client Architecture
Contents
SupportSoft Client Architecture........................................................................................................... 5
Overview............................................................................................................................................. 5
Client Main Components ............................................................................................................... 5
Folder Structure and Main Configuration Files.............................................................................. 5
Snapins and Snapin Types ........................................................................................................... 6
Global Configuration Settings........................................................................................................ 7
Milestones ..................................................................................................................................... 9
Steplist Snapin Architecture ............................................................................................................. 10
URL Step Types .......................................................................................................................... 10
Function Step Type ..................................................................................................................... 11
GetReg Step Type....................................................................................................................... 11
SetReg Step Type ....................................................................................................................... 12
GetParam Step Type................................................................................................................... 12
SetParam Step Type ................................................................................................................... 12
Steplist Step Type ....................................................................................................................... 12
Placeholder Step Type ................................................................................................................ 13
Flow API Snapin Architecture........................................................................................................... 14
Overview...................................................................................................................................... 14
The Flow API Snapin XML Format..............................................................................................14
Flow API XML Sections ............................................................................................................... 17
Flow API Snapin - API Functions ................................................................................................ 18
Flow API Snapin Events .............................................................................................................. 21
Flow API Snapin - API Configuration Options............................................................................. 22
The Flow API Snapin Flow Databag Format ...............................................................................23
Stand Alone Snapin Architecture...................................................................................................... 24
Overview of Building Software Packages v6.5 SP5 ......................................................................... 24
SupportSoft Client User Interface Architecture................................................................................ 26
Overview........................................................................................................................................... 26
User Interface Design ....................................................................................................................... 26
Configuring the SupportSoft Client User Interface .......................................................................... 29
SupportSoft Client Application Container (bcont.exe) ...................................................................... 29
Overview...................................................................................................................................... 29
SupportSoft Client Application Container Configuration File (bcont.ini)...................................... 29
Enabling and Disabling Snapins....................................................................................................... 33
Snapins With Tabs ...................................................................................................................... 34
Branding the SupportSoft Client User Interface............................................................................... 36
Overview........................................................................................................................................... 36
Branding Procedures ........................................................................................................................ 36
Setting up a Client for Testing/Customizing ................................................................................ 36
Creating a Custom Branded Skin for the SupportSoft Client User Interface .............................. 37
Customizing the SupportSoft Client Program Icons.................................................................... 44
Creating new DNAs for Custom Branded SupportSoft Client Components................................ 45
Clearing the Client History........................................................................................................... 49
Advanced User Interface Customization........................................................................................... 50
Adding a New Page to an Existing Snapin ....................................................................................... 50
Setting Up a Client System for Testing/Customizing .................................................................. 50
Customizing the Source Code..................................................................................................... 50
Clearing the SupportSoft Client History....................................................................................... 53
SupportSoft, Inc.
3
SupportSoft Client Architecture
Testing the New Page Customization ......................................................................................... 53
Adding a New Snapin to an Existing Flow........................................................................................ 55
Setting Up a Client System for Testing/Customizing .................................................................. 55
Customizing the Source Code..................................................................................................... 55
Clearing the SupportSoft Client History....................................................................................... 58
Testing the New Snapin Customization ...................................................................................... 58
Updating a DNA with Client Customizations .................................................................................... 60
SupportSoft, Inc.
4
SupportSoft Client Architecture
SupportSoft Client Architecture
This section describes the SupportSoft client software architecture.
Overview
The SupportSoft v6.5 client is designed so that all of the current SupportSoft Client-based
products and any future products can share a common client-platform architecture. This
structure is shared by the latest releases of SmartAccess, Repair Manager, System
TuneUp and Subscriber Agent.
Client Main Components
The SupportSoft client products are comprised of a shell, one or more UI skins and a set
of snapins which are bundled and operated upon based on product specific configuration
settings defined in XML. The following more clearly define these components:
•
Product: Product is a combination of shell and snapins bundled and operated
upon based on product specific configuration, such as SmartAccess, Repair
Manager, Subscriber Agent or System TuneUp.
•
Shell: The shell is the client UI framework that uses product configuration and
provides APIs to implement branding and other UI elements, container
management which includes localization and loading/unloading of snapin host
pages.
•
Snapins: Snapins are feature specific modules controlled by a host file which are
developed independently and then included in products. Snapins can be sets of
pages called step lists, or a single page that hosts a specific flow or even stand
along pages. Snapin hosts handle the communication between snapins using
events, and navigation between snapins.
•
History: XML based file that stores databag and navigation type elements loaded
into application memory. Navigation type contains the entire application flow in the
sequence it occurs (shown to user). Databag type is internally used application
level variables available at all scopes to all snapins of the applications.
Folder Structure and Main Configuration Files
All client products consist of two top level folders, one called \sscommon that is a shared
folder used by all of the client products which contains common files and shared snapins,
and a product specific folder which contains product specific files.
For example, for the SmartAccess product the product specific folder called smartaccess
and the configuration file at the root of that folder is called smaconfig.xml. In some
cases, the product specific folder with the configuration file may be one folder lower
because two or more products may share several common components. For example,
Subscriber Agent and Repair Manager are share 75% of the same code and snapins and
the differences are that one designed for Enterprise deployment and the other is
designed for DSP deployments. As such they both reside under the same product
specific folder called Agent, and then each one has its own product specific folder, one
called \repairmgr and one called \subagent.
At the same level as these two folders is a folder called \common which contains all of
the software components which are shared by both of these products. In this case, the
main product configuration files are under the product specific folder, so for Repair
Manager its \agent\repairmgr\repairmgr_config.xml, and for Subscriber Agent, it's
associated \agent\subagent\subagent_config.xml file.
SupportSoft, Inc.
5
SupportSoft Client Architecture
Each snapin is defined within a snapin-specific subfolder located under a main \snapins
folder. There are main \snapins\ folders in several locations, for example there is one
under the \smacommon main folder to host all the snapins that are shared among
products, and there is typically a \snapins folder under a \common folder under each
product and then there are also usually \snapins folders under flow specific folders below
the product folders, such as \smartaccess\cable\snapins\ to host snapins that are
specific to a specific flow within a product.
At the root of each \snapins folder are the html files that comprise the main code for the
snapin. Each \snapins folder contains the following subfolders:
•
\inc: This folder contains include files that are specific only to that snapin.
•
\lang: This folder contains one or more language subfolders, such as \en, each of
which contain all the text strings defined as XML variables which are used to
define all strings used within the snapin pages, for the specified language.
•
\xml: This folder contains the XML navigation flow file(s) for the snapin.
Snapins and Snapin Types
The SupportSoft Client based products use snapins to define all pages and flows.
Snapins are feature specific modules that are developed independently and then
included in products. Snapins that are shared between multiple products, or product sets
such as Subscriber Agent and Repair Manager, are stored in the \sscommon\snapins\
folder so they can be accessed from any products. Snapins that are product specific are
stored in a \snapin\ folder that resides under the product specific folder. Each snapin is
controlled by a snapin host file which is specified by the <config name="Startpage">
XML section within the main configuration file within the XML definition of each snapin.
There are three basic types of snapins:
•
Steplist: A sequence of steps implemented by multiple pages. For details on
steplist snapins.
•
Flow API: A continuous flow implemented by a single page based on a common
API.
•
Stand Alone: A single stand alone page used the implement a feature that has
no sequence or flow.
All snapin .htm files include the /sscommon/common/inc/ss_pageinclude.js. This file
loads several global variables that can be accessed by all snapins, and it automatically
detects the snapin type and loads additional includes if necessary. For example, snapins
of type flowapi also include the files flowapi.js and ss_flowapi_client_bridge.js files to
allow the snapin pages to access the required APIs.
A single snapin can contain other snapins and the basic flow of any client is defined in a
main configuration .xml file at the root of the product specific folder. All of the snapins are
listed in the <config-section name="snapins"> section of the main configuration file,
and then each snapin is defined within its own XML section within that file. The snapin
definition set parameters and locations for where the actual snapin exists.
The following code segment shows the SmartAccess snapins list that is defined in the
sma_config.xml file:
SupportSoft, Inc.
6
SupportSoft Client Architecture
<config-section name="snapins">
<config name="show_snapin_bar">0</config>
<config name="starting_snapin">snapin_installer</config>
<config name="allowed" type="list">
<config-item>snapin_installer</config-item>
<config-item>snapin_minreq</config-item>
<config-item>snapin_software</config-item>
<config-item>snapin_wireless</config-item>
<config-item>snapin_getconnect</config-item>
</config>
</config-section>
The following code segment shows the definition for the snapin_installer snapin which is
a steplist type snapin defined in the sma_config.xml file:
<config-section name="snapin_installer">
<config name="type">steplist</config>
<config name="reset_on_complete">false</config>
<config name="auto_start">false</config>
<config
name="snapinpath">%ROOTPATH%%PRODUCT%\common\snapins\installer\</config>
<config name="flow">%SNAPINPATH%xml\sma_inst_dslflow.xml</config>
<config name="includes" type="list">
<config-item>%SNAPINPATH%inc\sma_inst_decisions.js</config-item>
</config>
Snapin Files
The following are the files that comprise snapins:
•
Snapin Host file HTML file: This file is required by all snapins to include common
JavaScript functions needed to implement the snapin and to define an IFRAME to
host the snapin user interface. This file is located at the root of the snapin folder.
•
Snapin Source HTML files: These are the source HTML files that define the user
interface and page features. Snapins may contain any number of source files and
as few as one. These files are also located at the root of the snapin folder.
•
Snapin Language Resource XML files: These files contain all string definitions
referenced by the snapin source HTML files. Every snapin source HTML file which
contains strings has a corresponding language resource file. These files are
located under a subfolder under the snapin called \lang\en for English, \lang\ja
for Japanese, etc. For snapins implemented in multiple languages, there is a
corresponding language resource file within each different language subfolder.
•
Snapin Navigation XML file: This file defines the steplist for this snapin and is
required for all snapins of type steplist. This file resides within an \xml subfolder of
the snapin.
Global Configuration Settings
Client features and UI can be customized by overriding default values with custom
values. The default values are set in the common section of the main configuration file,
which is defined by the <config_default> section. This can be overridden if another
configuration is set by <config_to_use>. In the example below, these two sections are
set to the same value, however, config_to_use could easily be changed to my_config if
a custom configuration called my_config were available.
<config_to_use>smacommon</config_to_use>
<configuration_default>smacommon</config_default>
<configuration name="smacommon"></configuration>
SupportSoft, Inc.
7
SupportSoft Client Architecture
Any custom configuration, also defined in the main configuration file, such as smacable
or smadsl for the SmartAccess product, can re-define settings with the same names that
are defined in the common section, in which case the custom configuration settings will
always override the default configurations.
The following is an example code snippet from the \smartaccess\sma_config.xml file.
This section describes global SmartAccess parameters that are used on multiple
SmartAccess pages.
<config-section name="global">
<config name="provider">q2-data2k</config>
<config name="product">SmartAccess</config>
<config name="reglookup">true</config>
<config name="reglookup_order">HKLM</config>
<config name="server">http://q2-data2k.qa.supportsoft.com:8169</config>
<config name="wg_shell_url">
%SERVER%/sscommon/common/snapins/shell/ss_shell.htm
</config>
<config name="wg_detect_timeout">5000</config>
<config name="uniqueemail_url">
%SERVER%/sdccommon/smartaccess/asp/sma_emailcheck.asp
</config>
<config name="wg_username">limited</config>
<config name="wg_password">connect</config>
<config name="disable_refresh">false</config>
<config name="disable_select">false</config>
<config name="copy_shortcut">true</config>
<config name="alert_virus">false</config>
<config name="alert_exit">true</config>
<config name="alert_reboot">true</config>
<config name="set_identify">false</config>
<config name="reg_cleanup">true</config>
<config name="version">6.9.992.0</config>
</config-section>
Global Attribute Definitions
The following configuration tag attributes are available in the global configuration section:
SupportSoft, Inc.
•
provider: The name of the ISP company.
•
Product: The name of the SupportSoft Client-based product.
•
reglookup: Boolean indicating whether or not reglookup should be used to
override common settings.
•
reglookup_order: Defines which registry section should be used first. If HKLM is
set, then HKLM settings will override HKCU.
•
server: A URL starting with http or https that points to the SmartAccess server for
subscribers in a walled garden. E.g. http://server.supportsoft.com:8169.
•
wg_shell_url: A URL that defines the location of the default shell application for
the Walled Garden.
•
wg_detect_timeout: The default timeout in for detecting the walled garden URL
in MS.
•
uniqueemail_url: The path, relative to server, to the sma_emailcheck.asp page
on your SmartAccess server. E.g. if the ASP file is located at
http://server.supportsoft.com:8169/sdccommon/smartaccess/asp/sma_emai
lcheck.asp, and the server value is http://server.supportsoft.com:8169, then
the value should be /sdccommon/smartaccess/asp/sma_emailcheck.asp.
8
SupportSoft Client Architecture
•
wg_username: The default username used to connect to a modem.
•
wg_password: The default password used to connect to a modem.
•
disableRefresh: If this attribute equals true, then the right-click menu and the
F5/CTRL+R/Page Refresh feature are disabled on all pages. If this attribute
equals false, then the user can use refresh features.
•
disableSelect: . If this attribute equals true, then using left-click to select screen
areas is disabled. If this attribute equals false, then using left-click to select screen
areas is enabled.
•
copyShortcut: If this attribute equals true, then a desktop shortcut to
SmartAccess is created when the program is run from a CD.
•
alertVirus: If this attribute equals true, then when SmartAccess is closed, it will
prompt the user to restart any anti-virus software they may have been running.
•
alertExit: If this attribute equals true, then when SmartAccess is closed, it will ask
the user if they are sure they would like to exit.
•
alertReboot: If this attribute equals true, then when SmartAccess determines that
a computer reboot is required, it will alert the user that the computer is about to
reboot. The reboot will not take place until the user allows it.
•
setIdentify: If this attribute equals true, then the accessibility option of showing an
identity number on each page of the flow is enabled. The identity numbers are
defined in the navigation flow. If this attribute equals false, then identity number on
each page are not shown even if they are defined in the navigation flow.
•
regCleanup: If this attribute is true, then SmartAccess will clean-up the Windows
registry when installation is complete. If Subscriber Agent is also installed, set
this value to false to leave the SmartAccess keys in the registry so that Subscriber
Agent can use the information.
•
version: The dataset version of the SmartAccess files.
Milestones
A milestone is a group of steps that represent a functional block of the installation flow
being completed. For example, SmartAccess uses the Introduction, Filters, Modem,
Wireless, Account, and Software milestones. Milestones are shown in the SmartAccess
UI with the milestone that SmartAccess is currently within highlighted. Milestones are
defined outside of steplists in the navigation XML file. The <milestones> tag has the
following elements:
•
milestone: The name of the milestone that appears in the UI.
•
id: This attribute is an integer that specifies the order the milestone appears in the
UI. Milestone ids are referenced by steps.
The following is a snippet from the sma_inst_dslflow.xml page from the SmartAccess
product that shows the milestone functionality:
<milestones>
<milestone id=”1”>Introduction</milestone>
<milestone id=”2”>Filters</milestone>
<milestone id=”3”>Modem</milestone>
<milestone id=”4”>Account</milestone>
<milestone id=”5”>Software</milestone>
<milestone id=”5”>Wireless</milestone>
</milestones>
SupportSoft, Inc.
9
SupportSoft Client Architecture
Steplist Snapin Architecture
A steplist snapin is a sequence of steps. The <config name="flow"> section for the
snapin definition in the main configuration file specifies the navigation .xml file used to
define the steps within a steplist snapin.
<config-section name="snapin_installer">
<config name="type">steplist</config>
<config name="reset_on_complete">false</config>
<config name="auto_start">false</config>
<config
name="snapinpath">%ROOTPATH%%PRODUCT%\common\snapins\installer\</config>
<config name="flow">%SNAPINPATH%xml\sma_inst_dslflow.xml</config>
<config name="includes" type="list">
<config-item>%SNAPINPATH%inc\sma_inst_decisions.js</config-item>
</config>
The navigation XML file for a steplist snapin defines all the steps, and determines which
steps are run and in which order. Each step has a type and there are eight step types, as
listed below:
•
URL
•
function
•
getreg
•
setreg
•
getparam
•
setparam
•
steplist
•
placeholder
Typically in a steplist, each step is implemented on its own page. Each steplist has a
main navigation XML file, which is specified within the <config name="flow"> section. In
some cases this may be <config name="flow" type="list"> where multiple navigation
files can be specified because there may be different navigation for different flow types.
For example SmartAccess may have a steplist that has different navigation for the cable
flow than it does for the DSL flow.
The following subsections describe each of the different step types.
URL Step Types
A step of type URL represents an individual page. Steps of this type must define the
following attributes:
•
from: Whether the page is from a walled garden or local or it is a network page.
•
name: Relative path to the URL of the page.
The following attributes are optional:
SupportSoft, Inc.
•
identity: The unique page ID for the step specified by the name attribute. If the
identify parameter is equal to true in the sma_config.xml, these page IDs are
shown in the SmartAccess UI as an accessibility feature.
•
milestoneid: Associates the step with a milestone specified by the <milestone>
element.
10
SupportSoft Client Architecture
•
progress: The amount of the steplist time that this step takes. This value is used
to calculate the progress indicator value in the SmartAccess UI.
•
checkpoint: If this value is set to true, this step location is immediately written to
the registry. Thus, if the program quits unexpectedly, once the reboot finishes, the
subscriber is returned to the same place in the SmartAccess flow.
Each step of type URL can receive string value parameters through a sub-element
named param. param has two required attributes:
•
name: The name of the parameter.
•
value: The value of the parameter.
The values passed as parameters are accessible in the target page.
The following step loads a local page named sma_welcome.htm from the
/common/html/ folder.
<step type="url" from="local" name="/common/html/sma_welcome.htm"></step>
Function Step Type
If a step element’s type attribute has a value of function, it requires only the following
attribute:
•
name: Function name. This function needs to be defined in
sma_inst_decisions.js.
Function steps allow the flow to branch based upon the return value of the
function. result sub-elements are used to determine the branching logic. These elements
allow jumping to steps in the current steplist, other steplists or even specific steps within
other steplists. The result elements require the following attributes:
•
type: Either steplist or step, depending on the type of the target.
•
value: What the function needs to return in order to match this result.
•
name: The name of the target step or steplist.
If the result wishes to go to a specific step in another steplist, then it should specify
steplist as its type and the name of the target steplist as its name. It must also specify the
following attribute:
•
innerstep: The name of the target step within the target steplist.
Function Step Type Example
The following step loads the /common/html/sma_getcreds.htm page, if the subscriber
can access the walled garden. If the subscriber cannot access the walled garden, then
SmartAccess goes to the no_walledgarden_connect steplist.
<step type="function" name="CanAccessWalledGarden">
<result type="step" value="true" name=”/common/html/sma_getcreds.htm”></result>
<result type="steplist" value="false" name=”no_walledgarden_connect”></result>
</step>
GetReg Step Type
Steps of type getparam function similarly to function steps where the function is hardcoded to retrieves a SmartIssue value from the registry.
The name attribute is the name of the SmartIssue property. getreg elements have two
additional attributes beyond those found in steps of type function:
SupportSoft, Inc.
11
SupportSoft Client Architecture
•
class: A required attribute that specifies the SmartIssue class to read.
•
const: An optional attribute that allows the name to refer to a pre-defined
constant. Essentially, when const is specified and set to true the name attribute is
evaluated as a JavaScript variable within an eval() routine. When const is not
specified or is anything other than true, the value attribute is evaluated as a literal.
•
Key: The key to retrieve from g_currPageParamsDict
SetReg Step Type
Steps of type setreg allow adding or replacing an existing SmartIssue value in the
registry. The name attribute is the name of the SmartIssue property. The value attribute
specifies the new value of the property.
•
class: A required attribute that specifies the SmartIssue class which contains the
key to be set.
•
const: An optional attribute that allows the name to refer to a pre-defined
constant. Essentially, when const is specified and set to true the name attribute is
evaluated as a JavaScript variable within an eval() routine. When const is not
specified or is anything other than true, the value attribute is evaluated as a literal.
•
Key: The SmartIssue key for which to set the new value.
•
Value: The value to assign to the specified registry key
GetParam Step Type
The getparam, setparam, getreg and setreg step types are simple utility functions for
doing common operations from within the navigation file. getparam steps function
identically to function steps where the function is hard-coded to retrieve a parameter
value from g_currPageParamsDict.
•
Key: The name of the parameter in g_currPageParamsDict from which to
retrieve the value.
•
const: An optional attribute that allows the name to refer to a pre-defined
constant. Essentially, when const is specified and set to true, the name attribute
is evaluated as a JavaScript variable within an eval() routine. When const is not
specified or is anything other than true, the value attribute is evaluated as a literal.
SetParam Step Type
Steps of type setparam add or replace an existing parameter value in
g_currPageParamsDict.
•
Key: The key to set in g_currPageParamsDict.
•
Name: The name of the parameter.
•
Value: The value used to set the parameter.
Steplist Step Type
A step can also be a pointer to the next steplist to run. At the end of a steplist, if there is
no decision function or pointer to next steplist, then navigation ends. The loaded steps
stay in the shell framework and are written to the registry when the application closes.
<step type="steplist" name="cd_stackup"></step>
SupportSoft, Inc.
12
SupportSoft Client Architecture
•
name: Name of the steplist.
You can also jump to a specific step within the target steplist by using the following
attribute:
•
innerstep: Instead of jumping to the start of the steplist specified by name,
adding this attribute jumps to a specific step within the target steplist.
Placeholder Step Type
A step of type placeholder is nothing but a named step. The system does not do anything
on this step, it simply continues moving through the steplist. As such, a placeholder is a
useful tool for marking a set point in a steplist. In addition, because navigation can be
customized through overriding, the placeholder step type provides a way to override an
existing steplist while keeping steps with all of the same names as the overridden steplist,
even when there is no actual corresponding page. The placeholder element requires one
attribute:
•
SupportSoft, Inc.
name: The name of the step.
13
SupportSoft Client Architecture
Flow API Snapin Architecture
This section describes the SupportSoft client Flow API Snapin type. The following main
topics are covered:
Overview
A Flow API Snapin is an ordered set of steps that diagnose a user’s problem and
presents the user with a solution to the problem. For example, a step in the Flow API
Snapin may determine that user has a problem: no IP address. The Flow API Snapin
would then present the user with a solution that would renew the user’s DHCP address.
A Flow API Snapin XML file is processed using the Flow API that is implemented in the
flowapi.js JavaScript file. The Flow API acts as an engine that executes each step
contained in the XML file. As the API processes the XML file, it generates events and
calls an event handler function that was registered during initialization by the host page.
The event handler receives an event object that contains the information needed for the
host page to display the appropriate information to the user.
The Flow API is implemented in /sscommon/common/inc/flowapi.js.
The Flow API Snapin XML Format
This section describes how the Flow API XML is formatted.
Terminology
The following list contains the common Flow API terms and their definitions.
SupportSoft, Inc.
•
flow: A Flow API Snapin is a set of ordered steps stored in an XML file. These
steps are called trickles. Trickles themselves are made up of drops; a flow is
made up of trickles and trickles are made up of drops.
•
trickle: A trickle is a group of drops. The reason that trickles exist is to group
related diagnoses into a single entity, usually to avoid displaying too much detail
to the user. For example, one trickle in a “Validate Network” Flow API Snapin
may be a “Hardware Check” that contains the following drops: “Check for Ethernet
Card”, “Check for Cables”, and “Check for Wireless Hub”. Rather than
bombarding the user with the details of each of these drops, you may want to just
display a message in the trickle, “Checking your Network Hardware”.
•
drop: A drop is the core object of a Flow API Snapin. A drop is made up of a
problem and solution pair. The API evaluates the problem script to determine if
there is a problem and if so, sends an event containing the solution URL.
•
problem: The problem contains script to diagnose if there is an error condition. If
there is a problem, the script returns true and the API sends an event containing
the solution URL.
•
solution: The solution is the URL to a page that contains a solution to the
problem, ideally an automated solution.
•
event: Events are generated by the Flow API Snapin API while executing the
XML file. For example, when the flow is executed, a “Flow Started” event is sent
to the host page’s event handler.
14
SupportSoft Client Architecture
•
flow databag: Often Flow API Snapins need to maintain information gathered
from the user or by problem scripts. In order to make data storage easier, the API
provides a storage area, the flow databag. Values are stored and retrieved from
the flow databag using the sfDataSet() and sfDataGet() API functions. Internally
the flow databag is an XML structure and the whole flow databag can be stored
and retrieved using the sfDatabagSet() and sfDatabagGet() API
functions. These functions are useful for persisting the flow databag, e.g. writing it
out to the file system and then loading it when the flow is run again.
A Simple Example
An example of a simple Flow API Snapin is listed below. This simple flow is made up of
two trickles. The first trickle contains two drops; the second trickle contains one drop.
The first drop checks for a value in the flow databag. If this value is not present, then
there is a problem and a solution page is displayed that prompts the user for the
value. The second drop is very simple and always returns a value of false, or “No
Problem”, and thus the flow just continues execution. The third drop is similar to the first
in that it checks for a value in the flow databag and displays a solution if the value is
missing. This simple example is shipped as part of the Flow API Snapin SDK.
SupportSoft, Inc.
15
SupportSoft Client Architecture
<flow>
<trickle name="trickle1" enabled="true">
<display>
<![CDATA[
this is <B>bold</B> trickle number one
]]>
</display>
<drop>
<parameter type="in/out" required="true" helpstring="the user's email address
that gets stored in the databag">email</parameter>
<problem>
<flowscript>
<![CDATA[
function DoCheck(strId)
{
var msg = "In DoCheck() for " + strId + "\n";
var xPath = "email";
var myData = sfDataGet(xPath);
var retVal = (myData == null);
if (retVal)
msg += "found data '" + xPath + "' = " + myData;
else
msg += "didn't find '" + xPath + "' so prompting user";
// alert(msg);
return retVal;
}
return DoCheck("test1");
]]>
</flowscript>
</problem>
<solution>
<description><![CDATA[this is solution1's "description"]]></description>
<url>./solutions/solution1.htm</url>
</solution>
</drop>
<drop>
<problem>
<flowscript>
<![CDATA[
function DoCheck(strId)
{
// alert("In DoCheck() for " + strId);
return false;
}
return DoCheck("test2");
]]>
</flowscript>
</problem>
<solution>
<url>./solutions/solution2.htm</url>
</solution>
</drop>
</trickle>
<trickle name="trickle2" enabled="true">
SupportSoft, Inc.
16
SupportSoft Client Architecture
<drop>
<parameter type="in/out" required="true" helpstring="the user's first name that
gets stored in the databag">firstname</parameter>
<problem>
<flowscript>
<![CDATA[
function DoCheck(strId)
{
var msg = "In DoCheck() for " + strId + "\n";
var xPath = "firstname";
var myData = sfDataGet(xPath);
var retVal = (myData == null);
if (retVal)
msg += "found data '" + xPath + "' = " + myData;
else
msg += "didn't find '" + xPath + "' so prompting user";
// alert(msg);
return retVal;
}
return DoCheck("test3");
]]>
</flowscript>
</problem>
<solution>
<url>./solutions/solution3.htm</url>
</solution>
</drop>
</trickle>
</flow>
Flow API XML Sections
The following subsections provide definitions for each of the XML sections.
1. <flow/>
The top-most element of the Flow API Snapin XML.
2. <dependency/>
This section contains a dependency for this flow, e.g. an object used by the flow or a
Javascript file included by the flow. There can be zero or more dependency sections per
flow.
Attributes:
•
type: The type of dependency, e.g. “object”.
3. <trickle/>
This section contains the trickles in this flow. There can be one or more trickles per flow.
Attributes:
SupportSoft, Inc.
•
name: A user-defined name for this trickle. This name attribute is passed to the
event handler as the event.trickleName property of the event object.
•
enabled: Either “true” or “false”. If this attribute is “false”, then this trickle is
skipped and no events are sent for this trickle or its drops. Defaults to “true”.
17
SupportSoft Client Architecture
4. <display/>
This section contains the optional display string for this trickle. There can be zero or one
display per trickle.
5. <drop/>
This section contains the drops in this trickle. There can be one or more drops per trickle.
6. <parameter/>
This section contains a list of the flow databag parameters that this drop
manipulates. There can be zero to many parameters per drop. The body of the parameter
is the user-defined name of the data element in the flow databag.
Attributes
•
type: “in”, “out”, or “in/out”.
•
required: either “true” or “false”.
•
helpstring: user-defined help text.
7. <problem/>
This section diagnoses the problem condition for this drop. There should be exactly one
problem per drop.
8. <flowscript/>
This section contains the problem diagnosis script for this drop. This script should return
true if there is a problem and false if there is no problem. If the script returns true, a “Drop
Fail” event is generated. If the script returns false, a “Drop Succeed” event is generated
and the flow execution continues. There should be exactly one flowscript per problem.
9. <solution/>
This section contains the solution to this problem. There should be exactly one solution
per drop.
10. <description/>
This section contains an optional description of the solution to this problem. There should
can be zero or one description per solution.
11. <url/>
This section contains the URL to the solution to this problem. There should be exactly
one URL per solution.
Flow API Snapin - API Functions
This section describes the Flow API Snapin API functions. The following are the basic
rules that apply:
•
The Flow API Snapin API functions begin with the prefix “sf”.
•
Flow API Snapin API globals begin with the prefix “sfg_”.
•
Flow API Snapin API constants begin with the prefix “sfc_”.
•
With only a few exceptions, the Flow API Snapin API functions return
sfc_Success on success and an error code, often sfc_Error, on failure.
The Flow API Snapin API functions are listed below in alphabetical order.
SupportSoft, Inc.
18
SupportSoft Client Architecture
12. sfCleanup()
This should be the last call to the flow engine to cleanup and delete the internal
structures.
Return Values:
sfc_Success on success and an error code, often sfc_Error, on failure.
13. sfDatabagGet()
Returns the complete flow databag as an XML string. Useful for persisting the flow
databag.
Return Values:
A string value containing the XML of the flow databag, “undefined” on error, e.g. the flow
databag is not loaded.
14. sfDatabagSet(strXML)
Set the flow databag based on an XML string. Useful for persisting the flow databag. The
XML tags must be the expected tags as retrieved using sfDatabagGet().
Return Values:
sfc_Success on success and an error code, often sfc_Error, on failure.
15. sfDataGet(strName)
Returns a simple value from the flow databag that was set using sfDataSet(). Returns
null if no matching value exists.
Return Values:
The value of this key from the flow databag, “null” if the key does not exist in the flow
databag, and “undefined” on error, e.g. the flow databag is not loaded.
16. sfDataRemoveAll()
Removes all values from the flow databag.
Return Values:
sfc_Success on success and an error code, often sfc_Error, on failure.
17. sfDataSet(strName, strValue)
Stores a simple name/value pair in the flow databag.
Return Values:
sfc_Success on success and an error code, often sfc_Error, on failure.
18. sfDependencyGet(strType)
Returns a dependency from the <dependency/> section of the flow. strType can be a
value or the empty string, “”. Returns null if no matching dependency exists.
Return Values:
The value of this dependency, “null” if the dependency does not exist in the flow, and
“undefined” on error, e.g. the flow is not loaded.
19. sfEventSend(objEvent)
SupportSoft, Inc.
19
SupportSoft Client Architecture
Sends an event to all registered event handler functions. This function is primarily an
internal function and is rarely called externally. However it is exposed in the API in order
in case you want to send custom events to your event handlers.
Return Values:
sfc_Success on success and an error code, often sfc_Error, on failure.
20. sfFlowContinue() - deprecated
Use sfFlowContinueAtNextDrop() instead.
sfFlowContinueAtCurrentDrop()
Continue the flow at the current drop.
Return Values:
sfc_Success on success and an error code, often sfc_Error, on failure.
sfFlowContinueAtCurrentTrickle()
Continue the flow at the current trickle, starting at the first drop.
Return Values:
sfc_Success on success and an error code, often sfc_Error, on failure.
21. sfFlowContinueAtNextDrop()
Continue the flow at the next drop.
Return Values:
sfc_Success on success and an error code, often sfc_Error, on failure.
22. sfFlowContinueAtNextTrickle()
Continue the flow at the next trickle.
Return Values:
sfc_Success on success and an error code, often sfc_Error, on failure.
23. sfFlowContinueAtStart()
Continue the flow at the beginning, or in other words, restart the flow. The values in the
flow databag remain intact.
Return Values:
sfc_Success on success and an error code, often sfc_Error, on failure.
24. sfFlowLoad(strFlowDataSource, nLoadType)
Load a flow into memory from its data source. To load a flow from an XML string, use a
nLoadType of sfc_LoadFromXML and pass the XML string in strFlowDataSource. To
load a flow from a local XML file or URL, use a nLoadType of sfc_LoadFromFile and
pass the filename or URL in strFlowDataSource. The default nLoadType is
sfc_LoadFromFile.
Return Values:
sfc_Success on success and an error code, often sfc_Error, on failure.
25. sfFlowReset()
Reset the flow’s internal state variables so that the next call to sfRunFlow() starts from
the beginning.
SupportSoft, Inc.
20
SupportSoft Client Architecture
Return Values:
sfc_Success on success and an error code, often sfc_Error, on failure.
26. sfFlowRestart() - deprecated
Use sfFlowContinueAtStart() instead.
27. sfFlowRun()
Start the flow at its current location. Usually this re-runs the current drop.
Return Values:
sfc_Success on success and an error code, often sfc_Error, on failure.
28. sfInit(pEventHandlerFunction)
This should be the first call to the flow engine to initialize the internal structures and
register the event handler function. Alternatively, you can register multiple event handlers
by passing in an array of function pointers instead of a single function pointer.
Return Values:
sfc_Success on success and an error code, often sfc_Error, on failure.
Flow API Snapin Events
The Flow API - Snapin API sends events to the event handler function that the host page
registered using sfInit(). The event handler receives one parameter, an event that is a
Javascript object. The properties of the event object depend on the event type. The types
of events sent to the event handler are listed below in alphabetical order. The properties
that each event object provides is listed under the event type.
29. sfc_EventDropFail
•
event.type = sfc_EventDropFail
•
event.trickleName = /flow/trickle@name
•
event. solutionName = /flow/trickle/drop/solution/@name
•
event.solutionUrl = /flow/trickle/drop/solution/url
Sent after a problem script returns true.
30. sfc_EventDropStart
•
event.type = sfc_EventDropStart
•
event.trickleName = /flow/trickle@name
Sent during flow execution when a drop is started.
31. sfc_EventDropSucceed
•
event.type = sfc_EventDropSucceed
•
event.trickleName = /flow/trickle@name
Sent after a problem script returns false.
32. sfc_EventFlowClear
•
event.type = sfc_EventFlowClear
Sent after a call to sfLoadFlow().
SupportSoft, Inc.
21
SupportSoft Client Architecture
33. sfc_EventFlowEnd
•
event.type = sfc_EventFlowEnd
Sent during flow execution when the flow ends.
34. sfc_EventFlowStart
•
event.type = sfc_EventFlowStart
Sent during flow execution when the flow is started.
35. sfc_EventLogMessage
•
event.type = sfc_EventLogMessage
•
event.level = the severity of the log message: “Debug”, “Warning”, or “Error”
•
event.decription = the text of the log message
See the “Flow API Snapin API Configuration” section for an explanation of when this
event is sent.
36. sfc_EventTrickleAdd
•
event.type = sfc_EventTrickleAdd
•
event.trickleName = /flow/trickle@name
•
event.display = /flow/trickle/display
Sent for each trickle after a call to sfLoadFlow().
37. sfc_EventTrickleEnd
•
event.type = sfc_EventTrickleEnd
•
event.trickleName = /flow/trickle@name
Sent during flow execution when a trickle ends.
38. sfc_EventTrickleReset
•
event.type = sfc_EventTrickleReset
•
event.trickleName = /flow/trickle@name
Sent for each trickle after a call to sfResetFlow().
39. sfc_EventTrickleStart
•
event.type = sfc_EventTrickleStart
•
event.trickleName = /flow/trickle@name
Sent during flow execution when a trickle is started.
Flow API Snapin - API Configuration Options
The behavior of the Flow API Snapin API can be configured by setting properties of the
global configuration object sfg_APIConfiguration. The available properties and their
values are described below.
40. CatchScriptExceptions
SupportSoft, Inc.
22
SupportSoft Client Architecture
The API can be configured to catch any exceptions raised in the script by setting
sfg_APIConfiguration.CatchScriptExceptions = true. If this value is true, the API logs
a message rather than raising the exception.
In a production environment, you probably do not want to raise an exception. Thus, you
should set sfg_APIConfiguration.CatchScriptExceptions = true and
sfg_APIConfiguration.LogLevelToAlert = sfc_LogLevelNone and process Log
Message events in your event handler.
Default value: false
41. LogLevelToAlert
Based on the level of a log message, you can configure the API to either use alert() or
send you a Log Message event when the API encounters an error. The API defines the
following levels of log messages in increasing severity:
1. Debug
2. Warning
3. Error
You can set sfg_APIConfiguration.LogLevelToAlert to one of the constants below:
•
sfc_LogLevelAll: Use alert() for all log messages
•
sfc_LogLevelDebug: Use alert() for Debug and higher log messages
•
sfc_LogLevelWarning: Use alert() for Warning and higher log messages; send a
Log Message event for any lower levels
•
sfc_LogLevelError: Use alert() for Error and higher log messages; send a Log
Message event for any lower levels
•
sfc_LogLevelNone: Send a Log Message event for all log messages
For example, if sfg_APIConfiguration.LogLevelToAlert = sfc_LogLevelWarning then
the API displays an alert() for Warning and Error log messages and it sends a Log
Message event for Debug log messages.
In a production environment, you probably do not want to use alert(). Thus, you should
set sfg_APIConfiguration.LogLevelToAlert = sfc_LogLevelNone and process Log
Message events in your event handler.
Default value: sfc_LogLevelWarning
The Flow API Snapin Flow Databag Format
The Flow API Snapin flow databag is stored internally as XML. Normally flow databag
users do not need to be aware of the format except perhaps when trying to seed the flow
databag with data. Persisting the flow databag should simply be a matter of using
sfDatabagGet() and sfDatabagSet() and writing the XML string to a data-store, e.g. the
file system.
Databag Format Example
The following is an example of the flow databag format:
SupportSoft, Inc.
23
SupportSoft Client Architecture
<sf_databag>
<sf_namevaluepairs>
<user_defined_name type=”javascript_type”>
<![CDATA[
user_defined_data
]]>
</user_defined_name>
</sf_namevaluepairs>
</sf_databag>
<sf_databag/>
The top-most element of the flow databag XML.
<sf_namevaluepairs/>
This section of the flow databag contains the simple name/value pairs that get set using
the API functions sfDataSet() and sfDataGet().
<user_defined_name/>
This section of the flow databag uses the name/value pair data passed into
sfDataSet(). The user supplies the user_defined_name that is used as the XML tag and
the value, user_defined_value, is stored in a CDATA section.
Attributes:
•
type: The JavaScript type of this value, e.g. boolean, string, or number. The type
is used to properly store and retrieve boolean and number values.
Stand Alone Snapin Architecture
Stand Alone snapins are typically implemented as single pages without the need for any
flow through the page, or the need for steps. A good example of this is the Software
Install snapin in SmartAccess. This snapin is simply a single page the presents the
software choices that are available to the users once they have properly configured their
connection. It simply presents checkboxes, allowing the users to select which software
they want to install and click the Install button. The page then installs the software that
the user chooses and returns the flow to the next snapin or page specified in the initial
steplist.
Overview of Building Software Packages v6.5 SP5
The SupportSoft Platform provides an Installation Management system that allows
administrators to take individual software components (files, controls, drivers, registry
settings, scripts, etc.) and combine them into a single installable MSI package. The
software components are organized into SupportSoft DNAs, which are typically prepackaged for use.
The Installation Management system provides interfaces to modify and customize the
DNAs and provides a mechanism to create new DNAs, so that administrators can
package any software components that may have changed..
Many products use common SupportSoft applications, like the Support Center, but
because each product or product set may include different Support Center components,
the Support Center MSI package is not included with the Platform. Instead, all of the
Support Center components are included in the form of DNAs, so that each customer can
build their own custom Support Center package that matches their specific needs
keeping the packages as thin as possible for network and internet deployment.
SupportSoft, Inc.
24
SupportSoft Client Architecture
The Build Packages page within the Support Administrator provides the interface for
building MSI packages based on DNAs. This page lists all DNAs that exist within the
system and allows administrators to select the DNAs they want and specify package
options, including creating SupportSoft client packages or creating additional .exe
installation packages for systems, such as Windows 98, that don't include the MSI
Installer.
SupportSoft, Inc.
25
SupportSoft Client Architecture
SupportSoft Client User Interface Architecture
This section describes SupportSoft Client User Interface Architecture. T
Overview
The SupportSoft Client products share a common architecture and common user
interface design. The system is designed to run in SupportSoft's Win32 Web application
container (bcont.exe), but some products such as SmartAccess, also run in Internet
Explorer using the same architecture. Currently this architecture is shared the following
SupportSoft Client-based products:
•
SmartAccess
•
Subscriber Agent
•
Repair Manager
•
System TuneUp
The SupportSoft Client User Interface is easily customizable and all screen text, graphics
and branding can be modified through very minor modifications to what is called the ‘skin’
by including your own images and making changes to a single configuration. More
complex user interface modifications are also easy to make and typically involve only
modifying XML and CSS files and still not having to modify any HTML.
User Interface Design
The basic user interface for of the SupportSoft Client is based the concept of interlinked
snapins. Each snapin is based on the following set of basic user interface components:
•
Shell Host Window
•
Snapin IFrame
The following diagram where these are used within the SupportSoft client user interface:
SupportSoft, Inc.
26
SupportSoft Client Architecture
All snapins are displayed within the main shell host window and are comprised of
standard components. In the top area of the Shell Host Window are typically the
company logo, and buttons for Help, Print, About, etc. This area is used to display the
same items no matter what snapin is displayed. The Snapin UI is displayed slightly
differently depending upon the Snapin type. For Flow API and Stand Alone type
snapins, the main UI is displayed directly within the Snapin IFrame, however, with the
Steplist type snapins, a there are two layers of IFrames. One hidden IFrame with no user
interface called the Steplist Host IFrame which provides the inter-step communication,
shared variables, history, and APIs that can be used by the steplist code that is displayed
within the main Snapin IFrame. The Steplist Host IFrame sits directly behind the main
Snapin IFrame so it is hidden and it contains on user interface elements, as shown in the
following diagram.
The main Steplist IFrame contains the code and UI specific for each step within a
steplist. The Steplist Host IFrame also keeps the navigation history and common shared
variables for the steps, allowing the Next and Back buttons and other shared
functionality/settings to work seamlessly so that the steps within the Steplist IFrame
don't have track that info and can be focused strictly on the individual steps.
Different client-based product display the frames differently, depending upon their needs,
however they are all based upon this simple architecture design. For example, the
Repair Manager uses a common menu on the left side of the interface, as shown below,
so the Shell Host Window is expanded to the left so that the menu items can sit on the
left side of the Snapin IFrame.
SupportSoft, Inc.
27
SupportSoft Client Architecture
SupportSoft, Inc.
28
SupportSoft Client Architecture
Configuring the SupportSoft Client User Interface
This chapter describes how to configure the SupportSoft Client User Interface.
SupportSoft Client Application Container (bcont.exe)
This section describes SupportSoft Client Application Container, the following topics are
covered:
Overview
The SupportSoft Client Application Container is comprised of two main files, an
executable file and a configuration file. The executable file that launches and runs the
container is called bcont.exe and the configuration file for the container is called
bcont.ini. If more than one SupportSoft Client-based application is installed on a system,
each application has its own version of the bcont.ini and bcont.exe files in folders
specific to the application installation.
SupportSoft Client Application Container Configuration File (bcont.ini)
By default, when the container is launched, bcont.ini has multiple sections for grouping
related application attributes. All attributes may not be applicable to all applications.
Some of these attributes can be superseded by application XML configuration files or
registry settings once the application is launched.
Bcont.ini Attributes and Settings
The following sections describe the sections and attributes that can be used in the
SupportSoft Container configuration file
Note: Within Bcont.ini, comments are specified by semi-colon (;) and attributes can be
disabled by simply inserting a semi-colon (;) in front of the attribute.
[PROVIDERINFO] Section
This section contains a singe setting that associates the client to a specific server.
•
provider: Sets the current context to the specified provider and checks portal
connectivity with the provider when needed for updates and logging. (Used in Repair
Manager and SmartAccess.)
[SETUP] Section
This section contains settings for container specific launch and UI parameters.
SupportSoft, Inc.
•
center: A value of 1 launches the application centered on the screen. A value of 0
launches the application in the upper left corner. (Used in Repair Manager and
SmartAccess.)
•
checkadmin: If this value is 1, then verify if the logged in user has admin
privileges. If user is not an admin then a message, {[BRANDSTRING] 29320}, is
displayed and bcont.exe will exit. Default is 0. (Used by SmartAccess.)
•
checksecuritysetting: A value of 1 checks security settings used for ActiveX
settings. Default is 0.
•
CtlShiftTOff: A value of 1 turns off Ctl+Shift+T key processing. Default is 0.
•
disableCtxMenu: A value of 1 disables the context menu. Default is -1. (Used in
Repair Manager.)
29
SupportSoft Client Architecture
SupportSoft, Inc.
•
disableDropTarget: A value of 1 disallows you from dropping a link or other file
into the bcont.exe window. If allowed, bcont.exe attempts to navigate to this drop
target. Default is 0. (Used in Repair Manager.)
•
EscKeyOff: A value of 1 turns off Esc key processing. Default is 0.
•
height: The bcont.exe application window display area height. (Used in Repair
Manager and SmartAccess.)
•
installobjects: A value of 1 automatically installs and registers objects defined in
[REGLIB] section. Default is 0. (Used by SmartAccess.)
•
min_ie_str: If the user system does not have at least the minimum version of
Internet Explorer installed as specified by min_ie_ver, this message is displayed.
(Used in SmartAccess.)
•
min_ie_ver: Minimum version of Internet Explorer required on the user system for
the application to run. (Used in SmartAccess.)
•
minimizebox: A value of 1 includes the Minimize and Maximize buttons in the
application title bar. This also starts bcont.exe minimized. A value of 0 does not
include the Minimize or Maximize buttons in the application title bar. Default is 0.
(Used in Repair Manager and SmartAccess.)
•
showImages: A value of 1 instructs the Web browser control instance to
download and display images and videos and background sounds according to
preferences in the .INI file, even if these have been disabled in the Internet
Explorer settings. Default is 0. (Used in Repair Manager.)
•
showWarning: A value of 1displays a pre-launch warning message. Refer to the
[BRANDSTRINGS] section for the string message and customizable ID. Default
is 0.
•
singleinstance: Configures bcont.exe application to run as a single instance or
multiple instance application. If this attribute is used, only one instance of the
application can be run at a time on a client system. If this attribute is removed or
commented out, then multiple instances of the application can be run at the same
time on a client system. Default is false. If true, only one instance of bcont.exe is
allowed. (Used in Repair Manager and SmartAccess.)
•
securityAttr: Internet security settings to be tested against the target Internet
Explorer.
•
spaceneeded: Minimum space, in bytes, of free disk space needed to copy DLLs.
(Used in Repair Manager.)
•
starthidden: A value of 1 starts the client in hidden mode. Starthidden. Default is
0. (Used in Repair Manager.)
•
starturl: First HTML page that appears when the bcont.exe is initiated. (Used in
Repair Manager and SmartAccess.)
•
sysmenu: A value of 0 removes the system menu from the bcont.exe browser
window Default is 1.
•
title: The bont.exe application window title bar text. (Used in Repair Manager and
SmartAccess.)
•
useabsolute: Absolute positioning value. Default is 0.
•
width: The bcont.exe application window display area width. (Used in Repair
Manager and SmartAccess.)
30
SupportSoft Client Architecture
[REGLIB] Section
This section contains the GUIDs for controls used in the user application. These are
controls that get downloaded to the client when window.external.InstallObjects() is
called. This is called on welcome.htm by default for most of the client applications.
•
dll[number]=[control]|[GUID]: Enumerates controls used in the user application.
(Used in SmartAccess.)
o
number: An integer used for easier reference than the GUID.
o
control: The control file name.
o
GUID: The unique ID of the control.
Example:
dll1=tgctlsi.dll|{01010e00-5e80-11d8-9e86-0007e96c65ae}
[PATHS] Section
This section contains settings for bootstrapping Internet Explorer. You can also specify
any new entry in this section. This essentially identifies executables. For example,
notepad=c:\windows\system32\notepad.exe specifies the location and identity of
Notepad.
The entries used by SupportSoft products are:
•
iebootstrap: The path to (Used in SmartAccess.)
•
iebootstrap%d: Where %d refers to the language ID. The
GetUserDefaultLangID function retrieves the language identifier of the current
user locale.
•
iesetup: The path to (Used in SmartAccess.)
•
iesetup%d: Where %d refers to the language ID.
The entries above relate to extracting the IEAK (Internet Explorer Administrator Kit) path
in the order specified.
1. If iebootstrap%d this is the IEAK path.
2. If it iebootstrap%d is not specified, then iesetup%d is the IEAK path.
3. If either of these files is specified, but does not exist in the specified location, or if
these entries are not specified, then iebootstrap is the IEAK path.
4. If iebootstrap is not specified, the iesetup is used as the IEAK path.
Example
iebootstrap=iesetup\en\ie6setup.exe /C:"ie6wzd.exe /S:""#e"" /B:#D\iebatch.txt /Q" /R:A
iesetup=iesetup\en\ie6setup.exe /C:"ie6wzd.exe /S:""#e"" /B:#D\iebatch.txt /Q"
In the above entries the relative path to ie6setup.exe is specified with respect to
bcont.exe followed by parameters that are used by ie6setup.exe.
[BRANDSTRINGS] Section
This section contains message strings and ID. This .ini file can be used to pass any
arbitrary program defined value to avoid hard coded values within an application. This
section is valid, but is not any longer used by many of the client-based product. The
defined values are:
SupportSoft, Inc.
31
SupportSoft Client Architecture
•
29312: Unable to launch application. Please restart your computer and try again.
Error code: %d
•
29313: It is highly recommended to close all the anti-virus and firewall
applications before continuing this setup. To continue, press "OK", or "Cancel" to
abort the installation.
•
29314: You must enable ActiveX control in your browser security settings to run
this install. To enable ActiveX control press "OK", or "Cancel" to abort the
installation.
•
29315: No IE Object
•
29316: You must have Internet Explorer version (%s) or higher to run this install.
Current version is (%s). To upgrade press "OK".
•
29317: Are you sure you want to quit?
•
29318: =Quit
•
29319: Your operating system is not supported by this installation.
•
29320: You are not currently logged into your computer as an Administrator. This
installer requires that the user be logged in as an Administrator. Please log out
and log back in as an Administrator, and then restart the installer.
•
29322: You must be online to run this install.
Example bcont.ini File for SmartAccess
The following is the listing of the bcont.ini file used with SmartAccess.
[BRANDSTRINGS]
29322=You need to be online to run the MSI install
[PATHS]
iebootstrap=software\iesetup\en\ie6setup.exe /C:"ie6wzd.exe /S:""#e""
/B:#D\iebatch.txt /Q" /R:A
iesetup=software\iesetup\en\ie6setup.exe /C:"ie6wzd.exe /S:""#e"" /B:#D\iebatch.txt
/Q"
[PROVIDERINFO]
provider=my_test_server
[REGLIB]
dll1=tgctlsi.dll|{01010e00-5e80-11d8-9e86-0007e96c65ae}
dll2=sdcnetcheck.dll|{01011300-5e80-11d8-9e86-0007e96c65ae}
dll3=ssmail.dll|{01119000-3e00-11d2-8470-0060089874ed}
dll4=tgctlpw.dll|{01118d00-3e00-11d2-8470-0060089874ed}
[SETUP]
center=1
checkadmin=1
EscKeyOff=1
height=518
installobjects=1
launchieak=1
min_ie_str=This application requires IE version (%VERCHECK%) to run. Your current
Internet Explorer version is %VERACTUAL%. Please upgrade your Internet Explorer
browser.
min_ie_ver=5.5
minimizebox=1
NotSupportedOS=%WIN95%;%WINNT%
offlinealert=1
regroot=SmartAccess_6.5
setruncmd=1
shortcutName=SmartAccess
SupportSoft, Inc.
32
SupportSoft Client Architecture
singleinstance=true
starturl=..\sscommon\common\snapins\shell\ss_shell.htm?config=..\..\..\..\smartaccess\
sma_config.xml&global:provider=my_test_server
title=SmartAccess 6.5 SP1
uninstallkey=SmartAccess
uninstallstr=SmartAccess
width=600
SupportSoft Client Application Container (bcont.exe) Command Line Options
This section describes the SupportSoft client application container executable file,
bcont.exe command line parameters. The following are command line options that can be
used when launching bcont.exe.
•
/starthidden: Opens bcont.exe without showing the screen. The code must
execute window.external.Focus(); to show the user interface.
•
/snapin=: Specifies the snapin to navigate to when opening the UI, as long as it
exists in the snapins.xml. This also hides the splash page as soon as the snapin
claims its ready (we do not “mask” the autostart of a snapin that is specified in
this manner). There are a couple of ways this works, for example,
/snapin=snapinLongName, opens the snapin titled snapinLongName, and
snapin=LongName also opens the snapin named snapinLongName even
though it doesn’t contain the snapin prefix. This is to shorten the length of the
command line which is limited to 255 chars)
•
/trigger: Opens the specified trigger based snapin. For example
/trigger=triggerIE opens the snapin named triggerIE.
•
/hidenav: When any command line argument has no parameter the Repair
Manager considers its ‘value’ to be true, so it’s the same as /hidenav=true. This
also hides the navigation from the UI by placing the UI in the “onstage”
presentation as declared in the CSS.
•
/autostart: Initiates automatic processing of the specified snapin. This requires a
/snapin= or /trigger= option to really be effective.
•
/entry: Determines the principal which is reported to the server about how the
application was opened, whether through trigger, system tray icon, desktop icon,
start menu icon, or ‘unknown’?
•
/context: Used when triggers pass in a context (trigger specific).
Enabling and Disabling Snapins
This section describes the various methods for enabling and disabling snapins within
SupportSoft Client based applications which run within the SupportSoft Client application
container, bcont.exe.
Snapins can be disabled or 'turned off' by removing them from the allowed list in the
main configuration file for each client product. Removing the snapin name from the
allowed list removes it's from the flow of snapins and from the home page in the case of
the Subscriber Agent or Repair Manager. If using the Repair Manager, this also removes
them from the menu bar.
Note: Although this will work for SmartAccess, removing any snapin from the
SmartAccess flow will break the SmartAccess flow since the pages are designed to go
one after another in a specific order.
The following is a listing of the 'Allowed' list from the main configuration XML file:
SupportSoft, Inc.
33
SupportSoft Client Architecture
<config name="allowed" type="list">
<config-item>snapin_firstrun</config-item>
<config-item>snapin_solutions</config-item>
<config-item>snapin_alerts</config-item>
<config-item>snapin_contactus</config-item>
<config-item>snapin_email_main</config-item>
<config-item>snapin_email_addaccount</config-item>
<config-item>snapin_email_fixaccount</config-item>
<config-item>snapin_email_info</config-item>
<config-item>snapin_email_faq</config-item>
<config-item>snapin_email_passwordprompt</config-item>
<config-item>snapin_protectrestore</config-item>
<config-item>snapin_protect</config-item>
<config-item>snapin_restore</config-item>
<config-item>snapin_undo</config-item>
</config>
For Example, to remove the Email Snapin, remove the following lines in RED:
<config name="allowed" type="list">
<config-item>snapin_firstrun</config-item>
<config-item>snapin_solutions</config-item>
<config-item>snapin_alerts</config-item>
<config-item>snapin_contactus</config-item>
<config-item>snapin_email_main</config-item>
<config-item>snapin_email_addaccount</config-item>
<config-item>snapin_email_fixaccount</config-item>
<config-item>snapin_email_info</config-item>
<config-item>snapin_email_faq</config-item>
<config-item>snapin_email_passwordprompt</config-item>
<config-item>snapin_protectrestore</config-item>
<config-item>snapin_protect</config-item>
<config-item>snapin_restore</config-item>
<config-item>snapin_undo</config-item>
</config>
Snapins With Tabs
Snapins with multiple pages, which are listed as Tabs also have entries in the snapin
allowed list. These are for snapin_sysinfo, snapin_protectrestore,
snapin_preferences and can be removed individually using the same method of simply
removing them from the allowed list as described above.
snapin_sysinfo:
snapin_sysinfo_summary
snapin_sysinfo_os
snapin_sysinfo_hardware
snapin_sysinfo_network
snapin_sysinfo_email
snapin_sysinfo_details
snapin_protectrestore:
snapin_protect
snapin_restore
snapin_undo
snapin_preferences:
snapin_pref_general
snapin_pref_userinfo
snapin_pref_modemselect
SupportSoft, Inc.
34
SupportSoft Client Architecture
These three snapins use tabs inside the main snapin IFrame. If you want to allow the
snapin but hide one of its tabs, you can do the following should do following. For
example, if you want to remove the snapin_sysinfo_summary tab from
snapin_sysinfo, perform the following:
1. Remove it from the snapin allowed list in the clientui_config.xml, as shown
below in RED:
<config name="allowed" type="list">
<config-item>snapin_firstrun</config-item>
<config-item>snapin_solutions</config-item>
<config-item>snapin_solution_viewer</config-item>
<config-item>snapin_sysinfo</config-item>
<config-item>snapin_sysinfo_summary</config-item>
...
<config-item>snapin_wireless</config-item>
<config-item>snapin_getassistance</config-item>
</config>
2. In the same file, clientui_config.xml, remove the RED line inside the
snapin_sysinfo section.
<config-section name="snapin_sysinfo">
<config name="type">standalone</config>
<config name="auto_start">1</config>
<config name="force_window_type">6</config>
<config
name="snapinpath">%ROOTPATH%%PRODUCTPATH%common\snapins\sysinfo\</config>
<config name="startpage">%SNAPINPATH%ss_tabbedprofile.htm</config>
<config name="langpath">%SNAPINPATH%lang\</config>
<config name="helppath">%SNAPINPATH%help\</config>
<config name="tabs" type="list">
<config-item>snapin_sysinfo_summary</config-item>
<config-item>snapin_sysinfo_os</config-item>
<config-item>snapin_sysinfo_hardware</config-item>
<config-item>snapin_sysinfo_network</config-item>
<config-item>snapin_sysinfo_email</config-item>
<config-item>snapin_sysinfo_details</config-item>
</config>
</config-section>
SupportSoft, Inc.
35
SupportSoft Client Architecture
Branding the SupportSoft Client User Interface
This section describes how to Brand the SupportSoft Client User Interface. This interface
is shared among several SupportSoft Client-based Products. Some of the examples used
throughout this section are for a specific product but these are also applicable to any of
the client-based products with the only difference being some of the configuration file
names and perhaps branding images.
Overview
This section describes how to to brand the SupportSoft Client software for Subscriber
Agent or Repair Manager with your own custom branding images, logo and colors.
Important: Obtain a clean (SupportSoft Client not already installed), non-server system
to set up for branding your SupportSoft Client User Interface. If you plan to use a system
that already has the SupportSoft Client installed or had it installed and removed, follow
the procedures outlined in the Clearing the SupportSoft Client History section of this
document.
Branding Procedures
Each step below is a link to a procedure that performs a specific task. Perform each of
these tasks in the order listed to complete the branding process. Make sure to complete
and verify each task before continuing to the next task.
1. Setting Up a SupportSoft Client for Testing/Customizing (Subscriber Agent/Repair
Manager)
Note: Only perform this step if you don't already have a test system setup.
2. Modifying the SupportSoft Client User Interface for Branding
3. Customizing the Icons for the SupportSoft Container and Tray Menu
4. Creating New DNAs for Custom Branded SupportSoft Client Components
Note: Make sure to use these new DNAs when building your custom package.
Setting up a Client for Testing/Customizing
This section describes how to set up and install a SupportSoft Client for testing and/or
customizing. This process entails building a SupportSoft Client test package and
installing it locally for testing and customizing.
Important: These procedures should be performed from the client system which you
plan to use for running/testing and customizing your client software. It's recommended
not to use the server system for this procedure.
1. Open the Support Administrator in a browser instance and navigate to the Getting
Started > Client Build Wizard page.
2. From the Select Package Type (Wizard Page 1 of 4) page, click the radio button
for SupportSoft Subscriber Agent Client (or Full Featured with User Interface
if using the Repair Manager) and click Next.
3. From the Configure Package Information and Options (Wizard Page 2 of 4)
page, enter Client Branding Test Package in both the MSI Package Name field
and Product Name field, unselect all of the checkboxes that are selected and
then click Next.
SupportSoft, Inc.
36
SupportSoft Client Architecture
4. From the Select Package DNAs (Wizard Page 3 of 4) page, uncheck only the
box for SupportSoft Client UI Post-Commands under the SupportSoft Client
UI category, and then click Next.
5. From the Build Package (Wizard Page 4 of 4) page, click Build Package to start
the build process. This takes a few minutes to build, wait until you see a Build
completed without critical errors message at the bottom of the page and then
click Continue (directly next to that message).
6. From the Manage Packages page that appears, locate your new package at the
bottom of the list of packages, and then click the Download MSI Icon ( ) to
install the package onto your local system.
7. Copy all the control files (all files in this folder) from their default download
location, C:\Program Files\Common Files\SupportSoft\Bin, to the ..\program
files\[Provider ID]\agent\bin folder.
Note: If the ..\program files\[Provider ID]\agent\bin folder does not exist, create
it before copying the control files.
8. From the file system on the server, open the file ..\program files\[Provider
ID]\agent\clientui_config.xml and make the following changes:
a. Change fastnet in the following tag value to your Provider ID:
<config name="provider">fastnet</config>
b. Change the URL listed in the following tag value to the URL of your server:
<config
name="server">http://visprtclient01.supportsoft.com:8169</config>
Confirming the Test Environment
Perform the following steps to verify that you have successfully completed the
procedures listed in the previous section.
1. From the Windows Explorer, navigate to ..\program files\[Provider
ID]\agent\bin\.
2. Double-click on the bcont.exe file.
3. If this launches the Subscriber Agent (or Repair Manager) application, then you
have successfully set up you test client environment.
Troubleshooting the Test Environment Setup
If based on the confirmation setups above, you have not successfully setup the test
environment, refer to the following troubleshooting procedures.
Problem: Nothing happens after clicking bcont.exe.
Solution: This happens when the SupportSoft Client cannot install the controls because
they are not present in the correct location. Make certain that you have correctly copied
the control files to the \bin folder under the ..\program files\[Provider ID]\agent\ folder
on your local drive. Remember that you may have to create the \bin folder.
Creating a Custom Branded Skin for the SupportSoft Client User Interface
This section describes how to create a custom branded skin to replace the default
`FastNet branded skin.
Important: The procedures described in this section should be performed from the client
system which you plan to use for running and customizing your client software.
SupportSoft, Inc.
37
SupportSoft Client Architecture
Overview
This example creates a 'SupportAgent' branded skin for the SupportSoft Subscriber
Agent to replace the default FastNet branded skin and assumes that you already have a
test client set up to use for the branding procedures. To create your own custom branded
skin, simply follow these procedures replacing the SupportAgent name and images with
your own similar items.
Note: To use the SupportSoft Branded images shown this document to follow this
example, right-click on the images displayed in the steps below and copy them to your
local system.
The clientui XML <config> section, and \agent\ folder are used for both the Subscriber
Agent and the Repair Manager products. The Subscriber Agent is implemented as the
default configuration (called subagent) and settings. The Repair Manager is
implemented as a custom configuration (called repairmgr) which includes settings that
override the default Subscriber Agent settings when Repair Manager is used.
Note: Although this example uses the Subscriber Agent, it is also applicable for the
Repair Manager. The only difference is that the Repair manager has a larger window size
to accommodate the menu on the left and the only thing you might need to do differently
is to create a larger splash screen image.
Procedures
Perform the following procedures to create a custom branded skin for the SupportSoft
Client User Interface:
Note: The first few steps involve modifying the main SupportSoft Client configuration file,
clientui_config.xml, to define a new custom <configuration> section and customize
that section to point to the new skin.
1. Open the file ..program files\[Provider ID]\agent\bin\bcont.ini and remove the
&configtouse=subagent (or &configtouse=repairmgr if using the Repair
Manager) from the starturl= statement on (or near) line 11 of the file.
2. Save the bcont.ini file and close it.
3. Open the file ..program files\[Provider ID]\agent\clientui_config.xml in an
editor.
4. To setup a custom configuration section to override settings from the main
configuration, near the top of the file, right below the initial comments, change the
following:
From:
<config_to_use>clientui</config_to_use>
To:
<config_to_use>ss_custom</config_to_use>
5. At the end of the file, right before the </sprt> entry which closes the file, add the
following lines to define a new ss_custom configuration section which is needed
to define the new skin:
<configuration name="ss_custom">
</configuration>
SupportSoft, Inc.
38
SupportSoft Client Architecture
6. Copy all of the lines between the <configuration name="subagent"> and its
corresponding </configuration> statements, or if using Repair Manger, all the
lines between the <configuration name="repairmgr"> and its corresponding
</configuration> statement. Then paste that copied text into the new section at
the end, between the <configuration name="ss_custom"> and its
corresponding </configuration> statement.
7. To change the text in the title bar of the container window and the text displayed
with the Windows task bar icon, perform the following: Inside the <config-section
name="shell"> section which is within your new <configuration
name="ss_custom"> configuration, change the following:
From:
<config name="title">Client UI Agent SP1</config>
To:
<config name="title">SupportAgent v1.0 TEST</config>
8. Copy the entire section called <config-section name="skin"> towards the top of
the file, copying from the initial <config-section name="skin"> line to closing
</config-section> line.
9. Paste this section at the bottom of the file between your new <configuration
name="ss_custom"> and </configuration> tags.
10. Within this new section, modify the following:
From:
<config name="skinname">fastnet</config>
To:
<config name="skinname">supportagent</config>
11. Replace all instances of %COMMON% in this section with ss_custom. There
should be 10 instances to replace.
12. Save the clientui_config.xml file and close it.
13. From the file system on you test client machine, copy the folder
\ss_common\common\skins\fastnet\ to a new folder at the same level called
\ss_custom\common\skins\fastnet\.
14. Rename the new folder to \ss_custom\common\skins\supportagent\.
Note: The next few steps involve modifying or replacing some of the default
FastNet skinned images with images of your own.
15. The following images were modified for this implementation under the folder
\ss_custom\common\skins\supportagent\images:
o
ssbr_splashscreen.jpg (or for Repair Manager
ssbr_splashscreen_760.jpg):
From the following image:
SupportSoft, Inc.
39
SupportSoft Client Architecture
To:
SupportSoft, Inc.
40
SupportSoft Client Architecture
Note: For Repair Manager you'll need a wider splash screen image that is 760 pixels
wide.
o
ssbr_header.gif
To:
o
ssic_aboutus.gif, ssic_help.gif, ssic_print.gif and ssic_sysinfo.gif :
From:
and
SupportSoft, Inc.
and
41
and
SupportSoft Client Architecture
To:
and
and
and
Note: These images have three states so that the application does not
require multiple images to get the roll-over and clicked state effects.
Instead of using multiple images for these effects, the application uses
styles to change the focus on the same image, avoiding any delays that
may occur when loading other images. All of the SupportSoft client Shell
Widgets are implemented this way.
o
ssrs_footer_texture.gif, and srs_header_texture.gif:
From (these appear similar, but are different in color and gradient):
and
To:
and
Note: The last change that needs to be made is for the header image style
in the \ss_custom\common\skins\supportagent\css\shell.css style
sheet to re-size the definition of the header image because the
ssbr_header.gif for the SupportSoft skin is much wider than the default
version under the FastNet skin.
16. Open the file \ss_custom\common\skins\supportagent\css\shell.css in an
editor.
17. Within the style definition for body.clsShell #ss_shl_HeaderImage, modify the
width entry from 168px to 465px.
18. Save the \ss_custom\common\skins\supportagent\css\shell.css and close it.
Confirmation
Perform the following steps to verify that you have successfully completed the
procedures listed in the previous section.
1. From the Windows Explorer, navigate to ..\program files\[Provider ID]\agent\.
2. Double-click on the bcont.exe file. Or, if your SupportSoft Client application
(Subscriber Agent or Repair Manager) is running in the tray menu on your system,
simply double click on its icon from the tray menu.
3. When the Subscriber Agent (or Repair Manager) application launches, the
SupportAgent Branded Splash screen should appear, not the default FastNet and
then you should see the following screen with your branding customizations:
SupportSoft, Inc.
42
SupportSoft Client Architecture
Troubleshooting
If you were unable to get to bet the branding to work correctly, then perform the following
troubleshooting procedures:
Problem: You launch bcont.exe as described in step 2 of the Check for Success
section above, the container appears, but nothing ever shows up in it.
Solution: Carefully check the clientui_config.xml file to make sure you have a
</configuration> close tag for every <configuration> tag that you added and </configsection> close tag for every <config-section> tag. If those are correct, carefully check
all of your modifications as this is a symptom of incorrectly formatted XML.
Problem: None of your customizations appeared after launching bcont.exe.
Solution: Make sure that you deleted the &configtouse=subagent in the bcont.ini file
as mentioned in step 1 of the Procedure Steps listed above. And, make sure you
modified the config_to_use XML parameter in the clientui_config.xml file as mentioned
in Step 4 of the Procedures Steps section listed above.
Problem: One or more of your modified images show up as missing images.
SupportSoft, Inc.
43
SupportSoft Client Architecture
Solution: Make sure you copied all the images over to the exact same name of the
previous images that they replaced.
Customizing the SupportSoft Client Program Icons
This section describes how replace the SupportSoft Client application icon and Tray
Menu icon with your own custom icon(s).
Procedures
Perform the following procedures to customize the SupportSoft Client program icons.
Note: These procedures should be performed from the client system for which you have
already branded the main interface items for your customized SupportSoft Client.
1. Create or obtain you own custom .ico file. Make certain that the file has at least
one 16x16 256 color format and one 32x32 256 color format included.
Note: If you want to use a different Icon for the Tray Menu than for the
SupportSoft Container, then you'll need two icons. For this example, we'll use the
same icon for both, as is used by the default FastNet implementation.
2. From the file system, copy the icon that you plan to use for the SupportSoft Client
container to the ..\program files\[Provider ID]\agent\bin\ folder.
3. Rename this icon to bcont.ico.
4. Also from the file system, copy the icon that you plan to use for your SupportSoft
Client in the Tray Menu to the ..\program files\[Provider ID]\bin\ folder.
5. Open the file ..program files\[Provider ID]\bin\tray_config.xml in an editor.
6. Modify the entry for <file_name>sprt.ico</file_name>, under the <icon>
section, to use the name of the icon you copied in step 5.
7. Save the tray_config.xml file and close it.
Confirmation
Perform the following steps to verify that you have successfully completed the
procedures listed in the previous section.
1. From the Windows Explorer, navigate to ..\program files\[Provider
ID]\agent\bin.
2. Double-click on the bcont.exe file.
3. When the SupportSoft Client application launches, after the Splash Screen, you
should see the Client User Interface application with the new icon in the top left
corner of the container window, and in the Windows task bar. The diagram below
shows the application with a modified SupportSoft icon.
SupportSoft, Inc.
44
SupportSoft Client Architecture
4. To confirm that the Tray Menu icon has been updated, close the SupportSoft
Client Tray Menu program if it already running by right clicking on the icon and
selecting Exit from the right-click menu.
5. From the Windows Start Menu, select Run.
6. From the Run command dialog, enter the following in the Open: field:
"[ProviderID path]\bin\sprtcmd.exe" /P [ProviderID]. For example, if your
ProviderID is ACME1 and you used the default installation path, this command
would be:
"C:\Program Files\ACME1\bin\sprtcmd.exe" /P ACME1
7. You should now also see your new icon in the Tray Menu. Note that clicking the
tray icon opens the SupportSoft Client application user interface.
Creating new DNAs for Custom Branded SupportSoft Client Components
This describes how to create new DNAs for your SupportSoft Client (Subscriber Agent or
Repair Manager) branding customizations. These modified DNAs then need to be used
to build your SupportSoft Client packages in place of the default SupportSoft DNAs that
contain the unbranded versions of the same components.
SupportSoft, Inc.
45
SupportSoft Client Architecture
Important: It is recommended not to update the default DNAs delivered from
SupportSoft, but rather to copy them, re-name the copy and then update the files in the
copy and use them to build your packages. If you modify the default DNAs, your
modifications could get overwritten during an upgrade of the SupportSoft System.
Procedures
Perform the following procedures to create a new DNA to contain your client branding
customizations.
Important: This procedure requires that you have already made all the desired branding
customizations on the SupportSoft Client and have that client installed on your local
system.
1. On your local file system with your customized client installation, create new
folders under ...\Program Files\, called ...\Program
Files\providerSprt\agent\bin\ and ...\Program Files\providerSprt\bin\
2. Copy the customized ...\Program Files\[providerID]\agent\clientui_config.xml
file into the new ...\Program Files\providerSprt\agent\ folder.
3. Copy your updated bcont.ico file from ...\Program
Files\[providerID]\agent\bin\bcont.ico file into the new ...\Program
Files\providerSprt\agent\bin\ folder.
4. Copy your updated try_config.xml and your new tray icon file ([your icon file
name].ico) file from ...\Program Files\[providerID]\bin\ into the new ...\Program
Files\providerSprt\bin\ folder.
5. Create a new folder within the same structure called ...\Program
Files\providerSprt\sscustom\common\skins\.
6. Copy the entire folder and contents of your new branded skin to the ...\Program
Files\providerSprt\sscustom\common\skins\ folder.
For example, SupportAgent (...\Program
Files\[providerID]\sscustom\common\skins\SupportAgent\) was used as the
skin name in the branding example, so in this case, the \SupportSoft folder and
its contents would be copied to the ...\Program
Files\providerSprt\sscustom\common\skins\ folder.
7. On the same system, open the SupportSoft Support Administrator (http://[fully
qualified server URL]/sdcadmin) and navigate to the Platform Configuration >
Installation Management > Build Packages page.
8. Locate and select the DNA titled SupportSoft Client UI Common Files, within
the SupportSoft Client UI category and click the Copy Icon ( ) from the action
icons list on the right side of the table for that DNA. This opens the DNA Editor.
Note: You must have Pop-ups enabled in order for the DNA Editor to open. And,
once it's open, you may have to click the Internet Explorer ActiveX Control
Information Bar to install the required DNA Editor Control.
9. From within the DNA Editor, use the tree menu on the left to navigate to the Data
Files section and then select the items c:\program
files\providerSprt\agent\clientui_config.xml and click the Delete DNA Item
Icon ( ) from the DNA Editor toolbar to delete that item.
10. Now, click the Add DNA Item Icon ( ) from the DNA Editor toolbar. From within
the Add Data File dialog, browse to the ...\Program Files\providerSprt\agent
folder and select the clientui_config.xml file and then click Open.
SupportSoft, Inc.
46
SupportSoft Client Architecture
Important: Click No when the mapping conflict prompt (shown below) appears to
keep the mapping turned off.
11. Repeat step 10, but this time navigate to the ..\Program
Files\providerSprt\agent\bin and select the bcont.ico, instead of the
clientui_config.xml file.
12. Click the Save Icon ( ) in the main toolbar and click OK to the prompt that
appears (Would you like to save this DNA and its contents to the server(s)?).
13. Within the Add DNA Description dialog that appears, enter a name for your new
DNA, such as SupportAgent Client UI Common, into the Display Name field,
and select SupportSoft Client UI from the Category dropdown selection box,
then click OK.
14. At this point, a file copy progress indicator appears showing the DNA files being
copied up to the server(s). When the dialog is finished, a prompt appears saying
DNA successfully published and uploaded. Click OK when you see this
prompt.
15. Locate and select the DNA titled SupportSoft Client Tray Icon Sprocket, within
the SupportSoft Client (Full Featured) category and click the Copy Icon ( )
from the action icons list on the right side of the table for that DNA. This opens the
DNA Editor.
16. From within the DNA Editor, use the tree menu on the left to navigate to the Data
Files section and then select the items c:\program
files\providerSprt\bin\tray_config.xml and click the Delete DNA Item Icon ( )
from the DNA Editor toolbar to delete that item.
17. Now, click the Add DNA Item Icon ( ) from the DNA Editor toolbar. From within
the Add Data File dialog, browse to the ...\Program Files\providerSprt\bin\
folder and select both the tray_config.xml file and the ...\Program
Files\providerSprt\bin\[your new icon file name].ico files and the and then
click Open.
Important: Click No when the mapping conflict prompt (shown below) appears to keep
the mapping turned off.
18. Click the Save Icon ( ) in the main toolbar and click OK to the prompt that
appears (Would you like to save this DNA and its contents to the server(s)?).
SupportSoft, Inc.
47
SupportSoft Client Architecture
19. Within the Add DNA Description dialog that appears, enter a name for your new
DNA, such as SupportAgent Tray Icon Sprocket, into the Display Name field,
and select SupportSoft Client UI from the Category dropdown selection box,
then click OK.
20. At this point, a file copy progress indicator appears showing the DNA files being
copied up to the server(s). When the dialog is finished, a prompt appears saying
DNA successfully published and uploaded. Click OK when you see this
prompt.
21. From the Support Administrator Build Packages page, locate and select the DNA
titled SupportSoft Client FastNet Skin, within the SupportSoft Client Skins
category and click the Copy Icon ( ) from the action icons list on the right side
of the table for that DNA. This opens the DNA Editor.
22. From within the DNA Editor, use the tree menu on the left to navigate to the Data
Files section and then select all the items from the list of files in the upper-right
pane of the DNA Editor Window. Then, click the Delete DNA Item Icon ( )
from the DNA Editor toolbar to delete the entire list of items.
23. Now, click the Add DNA Item Icon ( ) from the DNA Editor toolbar. From within
the Add Data File dialog, browse to the ...\Program
Files\providerSprt\sscustom\common\skins\[custom skin name]\ folder,
select all the files within that folder and click Open.
Important: Click No when the mapping conflict prompt (shown below) appears to
keep the mapping turned off.
24. Click the Save Icon ( ) in the main toolbar and click OK to the prompt that
appears (Would you like to save this DNA and its contents to the server(s)?).
25. Within the Add DNA Description dialog that appears, enter a name for your new
DNA, such as My Custom Skin, into the Display Name field, and select
SupportSoft Client Skins from the Category dropdown selection box, then click
OK.
26. At this point, a file copy progress indicator appears showing the DNA files being
copied up to the server(s). When the dialog is finished, a prompt appears saying
DNA successfully published and uploaded. Click OK when you see this
prompt.
Confirmation
Perform the following steps to verify that you have successfully completed the
procedures listed in the previous section.
1. Use the Client Build Wizard page in the Support Administrator, in the Getting
Started section to build a new client package making sure the select the new
DNAs and unselect the original DNAs on Page 3 of the Client Build Wizard.
2. Use a clean client system to install the new package directly from the Support
Administrator Manage Packages page that appears when the Client Build
Wizard is complete.
SupportSoft, Inc.
48
SupportSoft Client Architecture
3. When the package finishes installing, run bcont.exe (...\Program Files\[Provider
ID]\agent\bcont.exe) and verify that the branded icons, text and images all
appear as expected.
Clearing the Client History
This section describes how to clear the SupportSoft client history from the file system and
registry of a system that has previously run the SupportSoft Client software.
This procedure is often necessary in a testing or customization environment where after
making customizations you may need to re-run the client software from the beginning as
if the software had not been previously run.
Procedures
Perform each of the steps listed in the following table to complete this task.
Note: This example procedure should to be performed from a system which has the
client software already installed and has already been run at least once.
1. Open the Windows Explorer.
2. Navigate to C:\Documents and Settings\[logged in username]\Local
Settings\Application Data\SupportSoft\[Provider ID]\ and delete the
[Provider ID] subfolder.
For example: If your Windows logged in username is john_k, and your Provider
ID is AcmePCs, then this would be C:\Documents and Settings\john_k\Local
Settings\Application Data\SupportSoft\AcmePCs\, and you would delete the
AcmePCs folder.
3. Open the registry editor: From the Windows Start menu, select Run, enter regedit
and click OK.
4. Navigate to HKEY_CURRENT_USER > SOFTWARE > SupportSoft >
ProviderList and delete the entry for your Provider ID.
For example: If your Provider ID is AcmePCs, then delete the AcmePCs registry
key under HKEY_CURRENT_USER > SOFTWARE > SupportSoft >
ProviderList.
5. Navigate to HKEY_LOCAL_MACHINE > SOFTWARE > SupportSoft >
ProviderList and delete the entry for your Provider ID.
For example: If your Provider ID is AcmePCs, then delete the AcmePCs registry
key under HKEY_LOCAL_MACHINE > SOFTWARE > SupportSoft >
ProviderList.
SupportSoft, Inc.
49
SupportSoft Client Architecture
Advanced User Interface Customization
This section describes how to customize snapins for any SupportSoft Client based
products. All of these products are based on the same SupportSoft Client Platform
architecture.
Note: The procedures written in this section used the SmartAccess client interface as
the example. When using the procedures listed in this section use the Subscriber Agent
or Repair Manager folders (..\[ProviderID]\Agent\) and the clientui_config.xml file
where the processes reference the ..\SmartAccess\ folder and sma_config.xml file.
Adding a New Page to an Existing Snapin
This section describes the process of adding a new page to an existing SmartAccess
Client Snapin. The example describes how to add a second page to the Filters steplist
within the SmartAccess Installer Snapin. The procedures described here can be used to
add a new page to any snapin within any of the client products.
Note: Although a final implementation of SmartAccess may use just a Walled Garden
MSI package or a Hotel Flow, this process requires you to install a SmartAccess CD Flow
client to implement and test customizations. The Walled Garden and Hotel Flow pages
are subsets of the CD Flow, and running client pages in the SupportSoft container is the
recommended method for testing customizations.
Each step below is a link to a procedure that performs a specific task. Perform each of
these tasks in the order listed to add a new page the Filters steplist. Make sure to
complete and verify each task before continuing to the next task.
1. Setup a system with a SupportSoft client installation for customizing and/or
testing.
Note: Only perform this step if you don't already have a test system setup.
2. Modify the SmartAccess source to add a new page to an existing snapin.
3. If you have previously run the client, clear the client history before testing your
changes.
4. Test the changes to confirm that the new page is properly implemented.
Setting Up a Client System for Testing/Customizing
Refer to the section titled Setting Up a Client for Testing in the Branding the SupportSoft
Client section of this document for details on setting up a clean client system for testing. If
you already have your test client installed, proceed to the next section.
Customizing the Source Code
This section describes how to customize the SupportSoft Client source code to add a
new page to an existing snapin. SmartAccess is used as the client software example in
this case. In this specific example, the existing Filters page is copied, modified and
added as a second page.
This involves the following two main steps:
1. Modifying the main SmartAccess configuration file, sma_config.xml by creating a
new custom configuration section to override configuration settings in the common
section.
2. Creating custom code to define the new filters page as listed below:
SupportSoft, Inc.
50
SupportSoft Client Architecture
o
New steplist source HTML file
o
Steplist language resource XML file
o
Steplist navigation XML file
Procedures
Perform each of the steps listed in the following table to complete this task.
Note: This example procedure needs to be performed from a system which has the client
software already installed.
1. Open the file \smartaccess\sma_config.xml in an editor.
2. At the end of the file, right before the </sprt> entry which closes the file, add the
following lines to define a new ss_custom configuration section which is needed
to host the new filters snapin:
<configuration name="ss_custom">
<config-section name="snapin_installer">
<config name="flow" type="list">
<config-item>%SNAPINPATH%xml\sma_inst_dslflow.xml</config-item>
<configitem>%ROOTPATH%ss_custom\common\snapins\filters\xml\sma_inst_custflow.xml
</config-item>
</config>
</config-section>
</configuration>
3. Near the top of the file, right below the initial comments, change the line shown
below.
From:
<config_to_use>smacommon</config_to_use>
To:
<config_to_use>ss_custom</config_to_use>
This tells the system to allow settings defined in the new ss_custom configuration
section to override any settings in the common configuration section.
4. Save the sma_config.xml file and close it.
5. From the file system, create a folder at the same level as \sccommon and
\smartaccess called \sc_custom.
6. Under this new folder, create the following directory structures to host the custom
code for the new filters page.
\sc_custom\common\snapins\filters\xml
\sc_custom\common\snapins\filters\lang\en
7. Create a new file called
\ss_custom\common\snapins\filters\xml\sma_inst_custflow.xml.
8. Within this file, add the following lines:
SupportSoft, Inc.
51
SupportSoft Client Architecture
<?xml version="1.0" standalone="no"?>
<navflow version="2">
<steplist id="filters" progress="5">
<step id="fil_sma_filters" type="url" progress="100" milestoneid="2"
page="sma_filters.htm">
</step>
<step id="fil_sma_filters2" type="url" progress="50" milestoneid="2"
page="%ROOPATH%ss_custom\common\snapins\filters\sma_filters2.htm">
</step>
<step id="fil_cd_stackup" type="steplist" innerstep="cdst_sma_modemselection"
targetid="cd_stackup">
</step>
</steplist>
</navflow>
9. Save the sma_inst_custflow.xml file and close it.
10. Open the file \smartaccess\common\snapins\installer\lang\en\sma_filters.xml
in an editor. Save this file to the following name and location:
\ss_custom\common\snapins\filters\lang\en\sma_filters2.xml.
11. Within this file, change the following items:
a. From: (items to change listed in red)
<res id="sma_filter_Header">Filters</res>
To: (changes listed in blue)
<res id="sma_filter_Header1">Filters2</res>
b. From: (items to change listed in red)
<res id="sma_filter_Content">
To: (changes listed in blue)
<res id="sma_filter_Content1">
c.
From: (items to change listed in red)
<![CDATA[ Filters separate voice signals from DSL signals so you can
talk on the phone and be online at the same time. Connect a filter to
the wall jack for all telephone devices that are on the same line (same
telephone number) as your DSL service. ]]></res>
To: (changes listed in blue)
<![CDATA[ This is an example of a second filters page.]]></res>
d. From: (items to change listed in red)
<res id="sma_filter_device_text">Devices could include:</res>
To: (changes listed in blue)
<res id="sma_filter_device_text1">More Devices could include:</res>
12. Delete the rest of the res id= entries in the page after the <res
id="sma_filter_device_text1"> entry (9 entries on consecutive lines).
13. Add the following two entries in the same location that you just deleted the other
<res> entries from:
<res id="sma_filter_other1">Other Device 1</res>
<res id="sma_filter_other2">Other Device 2</res>
14. Change the following lines:
a. From: (items to change listed in red)
SupportSoft, Inc.
52
SupportSoft Client Architecture
<res id="sma_filter_directions" type="html">
To: (changes listed in blue):
<res id="sma_filter_directions1" type="html">
b. From: (items to change listed in red)
<div id="sma_filter_device_text"></div>
To: (changes listed in blue):
<div id="sma_filter_device_text1"></div>
15. Delete all of the lines starting with <li id= below the <div
id="sma_filter_device_text1"></div> line.
16. Add the following two entries in the same location that you just deleted the other
entries from:
<li id="sma_filter_other1"></li>
<li id="sma_filter_other2"></li>
17. Save the sma_filters2.xml file and close it.
18. Open the file \smartaccess\common\snapins\installer\sma_filters.htm in an
editor and save it to the following name and location:
\ss_custom\common\snapins\filters\sma_filters2.htm.
19. Within this file, change the following items:
From: (items to change listed in red)
<div id="sma_filter_Header" class="clsPageHeader"></div>
<div id="sma_filter_Content" class="clsPageContent"></div>
<div id="sma_filter_directions" class="clsPageContent"></div>
To: (changes listed in blue):
<div id="sma_filter_Header1" class="clsPageHeader"></div>
<div id="sma_filter_Contt1en" class="clsPageContent"></div>
<div id="sma_filter_directions1" class="clsPageContent"></div>
20. Save the sma_filters2.htm file and close it.
Clearing the SupportSoft Client History
Refer to the section titled Clearing the SupportSoft Client History in the Branding the
SupportSoft Client section of this document for details on clearing the client history before
testing customizations.
Testing the New Page Customization
This section lists the procedures for testing the modifications made to the Filters steplist
for the previous procedures.
The filters pages are designed only to be accessed when there is no Internet
connectivity. Because of this, the testing procedures listed below require you to
temporarily disable your network connection in order to access the Filters section of the
SmartAccess client flow.
Procedures
1. Perform each of the steps listed in the following table to complete this task.
SupportSoft, Inc.
53
SupportSoft Client Architecture
Note: These procedures should be performed from the same client system that
contains the customized client software.
2. Use one of the following two methods to disable Internet connectivity from your
test system:
a. Unplug the Network cable from the back of your PC (only works when
using a non-wireless connection)
or
b. Go to your Network Connections window and temporarily disable all
connected Networks. To do this perform the following:
i.
From the Desktop, right-click on the My Network Places icon.
ii.
Under the LAN or High-Speed Internet heading, locate any
connection that have a status marked as Connected.
iii.
Right-click on the each connected network or Internet connection
and select Disable from the right-click menu.
3. From the Windows Explorer, navigate to ..\program files\[Provider
ID]\smartaccess\.
4. Double-click on the bcont.exe file to launch the SmartAccess application.
5. At the first screen, select English as the Language and then click Next at the
bottom of the page.
6. On the next screen, End User License Agreement, select the I Agree radio
button and click Next at the bottom of the page.
7. On the next screen, select install my modem and click Next at the bottom of the
page.
8. On the next screen, Installation Overview, simply review the list of steps,
confirming that "Install Filters and Cables' is listed, and click Next at the bottom of
the page.
9. On the next screen, wait for the minimum requirements check to complete and
then click Next at the bottom of the page.
10. The next screen is the default Filters page.
11. Click Next at the bottom of the page to go to your new page.
12. The screen should now be displaying your new filters page titled Filters 2. If you
see this page at this point, then you have successfully completed this task.
13. Re-enable your network: Either plug your cable back in, or go back to the Network
Connections Window, perform the same procedure as outlined in step 1 of this
procedure except select Enable from the right-click menu on the Internet or
network connection rather than Disable. Note that once you re-enable the
network, you won't be able to get back to the Filters page.
Troubleshooting
If you were unable to get to the new Filters page, then perform the following
troubleshooting procedures:
Problem: The Filters step was not listed in the list of steps on the Installation Overview
page described in Step 7 above.
SupportSoft, Inc.
54
SupportSoft Client Architecture
Solution: This happens when Internet connectivity is still enabled. You must make
certain that your system has no Internet connectivity at all before the filters pages shows
up. In some cases, you may have both a wireless Internet connection and a wired
connection, make certain that both are disabled, and that your system is not accessing
the Internet using a modem.
Problem: Everything seemed to work fine, except my new page never showed up after
the first filters page, the flow went directly to the Select Modem page.
Solution: Go back to the Customizing the Source Code section of the procedures and
confirm that you properly added a new entry for this page in the sma_inst_dslflow.xml
file, and that it references the new snapin source .htm file, and that the new snapin
source .htm file exists and is in the proper folder.
Adding a New Snapin to an Existing Flow
This section describes how to add a new snapin to an existing client flow. The procedure
uses SmartAccess as the example client application. The process is an example of
adding a new snapin to the default SmartAccess CD flow. The example used in this
section takes the Filters steplist that is part of the main SmartAccess Installer snapin and
modifies it to become its own steplist type snapin, which is launched from the Installer
snapin.
Note: Although your final implementation may use just a Walled Garden MSI package or
a Hotel Flow, this process requires you to install the SmartAccess CD Flow client to
implement and test customizations. The Walled Garden and Hotel Flow pages are
subsets of the CD Flow, and running client pages in the SupportSoft container is the
recommended method for testing SmartAccess customizations.
Each step below is a link to a section that performs a specific task. Perform each of these
tasks in the order listed to complete this process. Make sure to complete and verify each
task before continuing to the next task.
1. Setup a client system with a SmartAccess client installation for customizing and/or
testing.
Note: Only perform this step if you don't already have a test system setup.
2. Modify the SupportSoft client source code to add a new steplist snapin for Filters.
3. If you have previously run the client, clear the client history before testing your
changes.
4. Test the changes to confirm that the new page is properly implemented.
Setting Up a Client System for Testing/Customizing
Refer to the section titled Setting Up a Client for Testing in the Branding the SupportSoft
Client section of this document for details on setting up a clean client system for testing. If
you already have your test client installed, proceed to the next section.
Customizing the Source Code
This section describes how to customize the SmartAccess client source in order to
change the filters steplist in the Installer snapin to become its own custom snapin within
the SmartAccess CD Flow. This involves the following two main steps:
SupportSoft, Inc.
55
SupportSoft Client Architecture
1. Modifying the main SmartAccess configuration file, sma_config.xml by adding a
new snapin to the snapins list, defining a new configuration section for the new
snapin and creating a new custom configuration section to override configuration
settings in the common section.
2. Creating custom code to define the new snapin, which includes creating a snapin
host HTML file, snapin source HTML file, snapin language resource XML file and
a snapin navigation XML file.
Procedures
Perform each of the steps listed in the following table to complete this task.
Note: This example procedure needs to be performed from a system which has the client
software already installed.
1. Open the file \smartaccess\sma_config.xml in an editor.
2. Within the section <config-section name="snapins">, directly below the entry for
<config-item>snapin_minreq</config-item>, add a new snapin entry to the
snapins list:
<config-item>snapin_filters</config-item>
Directly before the first </configuration> entry, which closes the <configuration
name="smacommon"> section, add the following config-section to define the
new filters snapin:
<config-section name="snapin_filters">
<config name="type">steplist</config>
<config name="snapinpath">%ROOTPATH%ss_custom\common\snapins\filters\</config>
<config name="flow">%SNAPINPATH%xml\sa_filters_navigation.xml</config>
<config name="startpage">%SNAPINPATH%sa_filters_host.htm</config>
<config name="langpath">%SNAPINPATH%lang\</config>
<config name="helppath">%SNAPINPATH%help\</config>
</config-section>
3. At the end of the file, right before the </sprt> entry which closes the file, add the
following lines to define a new ss_custom configuration section, which is needed
to host the new filters snapin:
<configuration name="ss_custom">
<config-section name="snapin_installer">
<config name="flow" type="list">
<config-item>%SNAPINPATH%xml\sma_inst_dslflow.xml</config-item>
<configitem>%ROOTPATH%ss_custom\common\snapins\filters\xml\sma_inst_custflow.xml</configitem>
</config>
</config-section>
</configuration>
4. Near the top of the file, right below the initial comments, change the line shown
below.
From: (items to change listed in red)
<config_to_use>smacommon</config_to_use>
To: (changes listed in blue)
<config_to_use>ss_custom</config_to_use>
This tells the system to allow settings defined in the new ss_custom configuration
section to override settings in the common configuration section.
5. Save the sma_config.xml file and close it.
SupportSoft, Inc.
56
SupportSoft Client Architecture
6. From the file system, create a folder at the same level as \sccommon and
\smartaccess called \sc_custom.
7. Under this new folder, create the following directory structures to host all custom
code for the new snapin.
\sc_custom\common\snapins\filters\xml
\sc_custom\common\snapins\filters\lang\en
8. Copy the file sma_filters.xml from the
\smartaccess\common\snapins\installer\lang\en\ folder to the
\sc_custom\common\snapins\filters\lang\en folder.
9. Open the file
\smartaccess\common\snapins\installer\xml\sma_inst_dslflow.xml in an
editor.
10.
Save this file to the following name and location
\sc_custom\common\snapins\filters\xml\sma_inst_custflow.xml.
11. Within this file, delete everything except the opening and closing <navflow>
statements and the entire cd_stacking steplist.
Note: Only a few individual steps in the CD Flow steplist need to be changed, but
the system will only overwrite the main flow at the steplist level and not at the step
level.
12. Within the cd_stacking steplist, modify the step titled
cdst_SI_INSTALL_USERTYPE with new code to specify using the new filters
snapin rather than the old filters URL step. Change the following.
From: (items to change listed in red)
<step id="cdst_SI_INSTALL_USERTYPE" type="getreg" class="SI_GEN_CLASS" const="true"
key="SI_INSTALL_USERTYPE">
<result type="steplist" value="new" targetid="filters"></result>
<result type="steplist" value="reinstall" targetid="filters"></result>
<result type="steplist" value="swap" targetid="modem_replace"></result>
<result type="step" value="2ndpcwireless" targetid="cdst_sma_modemselection"></result>
</step>
To: (changes listed in blue)
<step id="cdst_SI_INSTALL_USERTYPE" type="getreg" class="SI_GEN_CLASS" const="true"
key="SI_INSTALL_USERTYPE">
<result type="step" value="new" targetid="cdst_snapin_filters"></result>
<result type="step" value="reinstall" targetid="cdst_snapin_filters"></result>
<result type="steplist" value="swap" targetid="modem_replace"></result>
<result type="step" value="2ndpcwireless" targetid="cdst_sma_modemselection"></result>
</step>
13.
Add the following line directly below the section that you just modified, before the
cdst_sma_modemselection step to define the new snapin:
<step id="cdst_snapin_filters" type="snapin" name="snapin_filters" milestoneid="2"
progress="5"></step>
14. Save the sma_inst_custflow.xml file and close it.
15.
Copy the file
sma_filters.htm from \smartaccess\common\snapins\installer\ to
16. \sc_custom\common\snapins\filters\.
17. Create a new file called
\sc_custom\common\snapins\filters\xml\sa_filters_navigation.xml.
SupportSoft, Inc.
57
SupportSoft Client Architecture
18. Within this file, add the following lines:
<?xml version="1.0" standalone="no"?>
<navflow version="2">
<steplist id="start">
<step id="sma_filters_start" type="url" page="sma_filters.htm"/>
<step id="flsu_ss_snp_Success" type="snapincomplete" name="ss_snp_Success"/>
</steplist>
</navflow>
19. Save the sa_filters_navigation.xml file and close it.
20. Create a new file called
\sc_custom\common\snapins\filters\sa_filters_host.htm.
21. Within this file, add the following lines:
<html>
<head>
<script type="text/javascript"
src="../../../../sscommon/common/inc/ss_pageinclude.js"></script>
</head>
<body>
<iframe id="ss_Snapin_Content_iFrame" allowTransparency="true" frameBorder="0"
hidefocus="hidefocus"></iframe>
</body>
</html>
22. Save the sa_filters_host.htm file and close it.
Clearing the SupportSoft Client History
Refer to the section titled Clearing the SupportSoft Client History in the Branding the
SupportSoft Client section of this document for details on clearing the client history before
testing customizations.
Testing the New Snapin Customization
This section tests the modifications made to the Filters steplist for previous set of
procedures. The Filters pages are designed only to be accessed when there is no
Internet connectivity. Because of this, the testing procedures listed below requires you to
temporarily disable your network connection in order to access the filters section of the
SmartAccess client flow.
Procedures
Perform each of the steps listed in the following table to complete this task.
Note: These procedures should be performed from the same client system that contains
the customized client software.
1. Perform each of the steps listed in the following table to complete this task.
Note: These procedures should be performed from the same client system that
contains the customized client software.
2. Use one of the following two methods to disable Internet connectivity from your
test system:
c.
Unplug the Network cable from the back of your PC (only works when
using a non-wireless connection)
or
SupportSoft, Inc.
58
SupportSoft Client Architecture
d. Go to your Network Connections window and temporarily disable all
connected Networks. To do this perform the following:
i.
From the Desktop, right-click on the My Network Places icon.
ii.
Under the LAN or High-Speed Internet heading, locate any
connection that have a status marked as Connected.
iii.
Right-click on the each connected network or Internet connection
and select Disable from the right-click menu.
3. From the Windows Explorer, navigate to ..\program files\[Provider
ID]\smartaccess\.
4. Double-click on the bcont.exe file to launch the SmartAccess application.
5. At the first screen, select English as the Language and then click Next at the
bottom of the page.
6. On the next screen, End User License Agreement, select the I Agree radio
button and click Next at the bottom of the page.
7. On the next screen, select install my modem and click Next at the bottom of the
page.
8. On the next screen, Installation Overview, simply review the list of steps and
click Next at the bottom of the page.
9. On the next screen, wait for the minimum requirements check to complete and
then click Next at the bottom of the page.
10. The next screen is the default Filters page. If you see this page then your new
snapin is working and you only need to confirm that the page exit functionality is
also working correctly.
11. Click Next at the bottom of the page to go to the Modem Selection Snapin. If you
see this page at this point, then you have successfully completed the process.
12. Re-enable your network: Either plug your cable back in, or go back to the Network
Connections Window, perform the same procedure as outlined in step 1 of this
procedure except select Enable from the right-click menu on the Internet or
network connection rather than Disable. Note that once you re-enable the
network, you won't be able to get back to the Filters page.
Troubleshooting
If you were unable to get to the new Filters page, then perform the following
troubleshooting procedures:
Problem: The Filters step was not listed in the list of steps on the Installation Overview
page described in Step 10 above.
Solution: This happens when Internet connectivity is still enabled. You must make
certain that you system has no Internet connectivity at all before the filters pages show
up. In some cases you may have both a wireless Internet connection and a wired
connection, make certain that both are disabled, and that your system is not accessing
the Internet using a modem.
Problem: The Filters page appeared blank.
Solution: Go back to the Customizing the Client Source to Add a New Snapin to an
Existing Flow step and confirm that you have added and modified all files correctly. A
missing file or incorrectly modified HTML or XML file can cause this problem.
SupportSoft, Inc.
59
SupportSoft Client Architecture
Updating a DNA with Client Customizations
This section describes how to update an existing DNA with new or updated files and/or
settings.
Important: It is recommended not to update the default DNAs delivered from
SupportSoft, but rather to copy them, re-naming the copy and then update the files in the
copy and use that to build your packages. If you modify the default DNAs, your
modifications could get overwritten during an upgrade of the SupportSoft System.
Procedures:
Perform each of the steps listed in the following table to complete this task.
Important: For this procedure, you should have the modified or updated versions of all
files and/or settings that you want updated in the DNA, loaded on you local system in the
same folder structure or registry hive that they are listed in the DNA, before beginning
this procedure.
1. Go to the Platform Configuration > Installation Management > Build
Packages page within the Support Administrator
Locate the DNA that you want to update and click the Edit Icon ( ) from the
action icons list on the right side of the table for that DNA. This opens the DNA
Editor.
Note: You must have Pop-Ups enabled in order for the DNA Editor to open. And,
once it's open, you may have to click the Internet Explorer ActiveX Control
Information Bar to install the required DNA Editor Control.
2. Locate the DNA that you want to update and click the Edit Icon ( ) from the
action icons list on the right side of the table for that DNA. This opens the DNA
Editor.
Note: You must have Pop-Ups enabled in order for the DNA Editor to open. And,
once it's open, you may have to click the Internet Explorer ActiveX Control
Information Bar to install the required DNA Editor Control.
3. From within the DNA Editor, use the Tree on the left to navigate to the section(s)
that contain the item(s) that you want to update. For each item you want to update
you'll need to delete that item and then click the Add DNA Item Icon ( ) from
the main menu and select the updated version of the same item from your local
system.
Note: This step requires that you have the updated software items installed on
your local system as mentioned in the Important note at the top of this section.
4. For each item that you want to add, click the Add DNA Item Icon (
main menu and select the items that you want to add.
) from the
5. Once you have deleted and re-added, or just added all the items that you want to
update in the DNA, click the Save Icon ( ) in the main toolbar and then close
the DNA Editor.
6. If an Add DNA Mapping prompt appears at this point, click No to keep the
mapping turned off.
Confirmation
Perform the following steps to verify that you have successfully updated the DNA.
SupportSoft, Inc.
60
SupportSoft Client Architecture
1. From the Build Packages page in the Support Administrator (Platform
Configuration > Installation Management > Build Packages), locate the
updated DNA in the list.
2. Click the Install Icon (
).
3. When the MSI Installation Dialog appears, click Run and follow the instructions
to install the software.
4. If the software is installed properly, then your MSI package was successfully
created.
SupportSoft, Inc.
61
SupportSoft Client Architecture
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertising