The Harness started out as a humble 'App' to send and receive MQ messages on the thin client, but it has since grown to become an indispensable tool for Siebel development and testing. This was introduced to readers on a previous post titled 'The Harness'
In case you missed it, here are some of its key features
* Simulate any Business Service from any screen with active context
* Run eScript on the fly in any object manager
* Construct & perform BC operations without scripting
* Send/receive MQ messages
* Base64 encode/decode, and previewing of Base 64 images
* Regular regression tester with result highlighting
* Generate random test data
* On the fly XML conversion between Siebel formats, and passing as an input into a BS
* Open UI API browser/console
These features were built for the developers of a specific client, but if you like the idea of building such a tool for your own project, this article provides an approach for the new breed of Siebel/Web solution designers out there to follow.
Architecture
The above diagram highlights the main components that make up The Harness. Each point will be discussed below.
1. The Harness UI
Provides an interface allowing developers to interact with your Tool.
The UI was hand built using HTML, with jQuery for handling the interactions, and providing the animations.
[Responsibilities]
Provides pretty UI for the user
Pretty prints ECMA Script/XML, displays tabular data
Data entry
2. The Harness Core
The core logic (written in Javascript, with support from jQuery) responds to user actions, orchestrates the work needed to construct requests, execute actions and formats the response before being displayed to the user.
[Responsibilities]
Interface with Storage bridge
Interface with Siebel API through Proxy
Interface with Server libraries through Proxy
Convert between different data representations
Constructs Request from data elements
3. Proxy
Communication between browser and server is managed through a custom proxy, which routes all browser commands to a common entry and exit point. The proxy communicates with the Siebel through a business service invocation, using PropertySets to transport data.
[Responsibilities]
Interfaces with Siebel API
Single point of communication between browser/server
Encode/decode HTML entities
Encodes/Decodes command from browser/server
4. Local data store bridge
The local data store bridge provides a high level API for interfacing with the available storage technologies on the browser. There are many 3rd Party storage libraries that provide this functionality, eg. LawnChair, jsStorage, PersistJS
[Responsibilities]
Interface with lower level browser Storage API
5. Third Party
Third Party libraries are used for syntax highlighting, JS code editor, JSHint, animation
[Responsibilities]
Adds sugar to The Harness
6. Local storage
Local storage is medium for persisting data on the Client. This can be Web SQL, IndexedDB, HTML Storage, Cookies, depending on what is supported on the users browser. The APIs for these storage options are different, so we’ve used the local storage bridge above to abstract the browser implementation from our logic.
[Responsibilities]
Persists client side preferences
Stores historical requests
Save to favourites
7. Browser (Siebel) UI
The Harness is linked to the Siebel UI. This means, we can get the active context of the current browser session, allowing us to implement a business service simulation interface that can work with TheApplication().GetActiveBusObject(). This also allows us to run browser script, or call Open UI’s new API.
[Responsibilities]
Launches The Harness
Interface with Siebel’s browser layer
Interface with Siebel’s active context
8. Server deployed components
This consists of custom script libraries, JAR files, WFs, supporting Business Services, and SRF modifications.
[Responsibilities]
Provide server support for our features
Challenges
Working external to the Siebel repository, and outside the guidelines of classical Siebel development brings some new challenges.
This is the world of the new hybrid Siebel/Web developer, but the lessons learnt here, is also applicable for traditional developers.
Supportability, Maintainability, Persistence, Session Attachment, Access Rights, Deployment
Supportability
When designing a solution, whether it be for Siebel, or for some other application, best practice dictates that we stick to the published supported interfaces.
Undocumented features in Siebel can be an ambiguous bucket.
There are a lot of ‘undocumented’ features in eScript as it is based on the ECMA specification. Siebel provides documentation for its eScript API, but not for all the ECMA scripts features, so projects need to make sound judgements on the use of these features, and have the in-house expertise on standby to support it.
However if you’ve discovered an undocumented user property, remember this isn’t part of any supportable standard. First consider the available alternatives, then choose to use it with caution, but have a contingency plan. User properties have faired quite well in upgrades compared to scripting alternatives.
However, if the solution depends on a hack, be prepared to lose that feature in a future upgrade.
The Harness was built pre Open UI, and has lasted upgrades through 8.1.1.15, 8.1.1.10, 8.1.1.11.
Maintainability
Can your solution be easily extended without too much effort? Your design, should limit the points of configuration, utilise common libraries, and separate configuration from code, this will help with maintainability and extensibility. Spend the time to refactor your code at key stages of its development.
Persistence
Like user preferences in Siebel, the goal of persistence is to remember changes in the state of the browser, and personalize the experience.
As a testing tool, The Harness was built to remember inputs for named test cases, and historical test runs. As a development tool, The Harness had to remember previous actions for recall, review, and reruns.
Cookies may be the first consideration for Siebel veterans who have a side interest in web technologies, but there are better modern alternatives such as HTML storage, Web SQL, Indexed DB. Unfortunately, the implementation isn’t quite standard across browsers, so the solution to this is to use a storage bridge to abstract your interface from the capabilities of the individual browsers.
Keep in mind that these are cached on the clients hard disk, if there is a requirement to have persistence across different machines, then the naturall place for this is on the server. The Harness utilizes a further layer of abstraction on top of the 3rd Party library, allowing it to switch to a different API without costly changes.
Session Attachment/Access Rights
The Harness UI is built from an independent HTML file, and needs to be launched by a user’s action. Considered placements for this launch, can range from the Application menu, from a button on an admin screen, short cut key launch, or via a visibility based icon.
This leads to the question of how to secure the tool from unauthorised access. My mentor once told me, the best security is non-disclosure, if the users don’t know it’s there, they won’t be able to use it!. Although there is some truth to that, The Harness employs a more secure approach by providing access rights through a server side administration screen.
Deployment
The Harness weighs in at more than 10Mbs, with server and client side artifacts. It was important to facilitate ease of installation, updates, and maintenance on the product.
The Siebel web server separates its resources into different locations for SCRIPTS, FILES, 3RDPARTY and IMAGES. Following this pattern makes sense, but it also makes it more error prone to deploy without a proper build process.
An ANT build process was implemented to facilitate deployment of external file resources.
Conclusion
Have your staff have been stuck troubleshooting why a piece of code runs differently in the users object manager, than the WF Object manager?. The Harness can dispatch a chunk of eScript to run on the Server, without costly compiles/deployment.
In a diferent scenario, a developer might be wondering why an XML payload, when transformed into a Siebel Message doesn’t 'upsert'. With The Harness the developer can take the transformed message, or handcraft a modified version, and test out different message structures on the fly, and upsert it without touching tools.
Siebel developers around the world have figured out ways to work smarter, and build competitive advantage through custom tools and processes. It’s in the DNA of every developer, hopefully these ideas inspires designers out there to take the next step to build unique solutions for your clients.
In case you missed it, here are some of its key features
* Simulate any Business Service from any screen with active context
* Run eScript on the fly in any object manager
* Construct & perform BC operations without scripting
* Send/receive MQ messages
* Base64 encode/decode, and previewing of Base 64 images
* Regular regression tester with result highlighting
* Generate random test data
* On the fly XML conversion between Siebel formats, and passing as an input into a BS
* Open UI API browser/console
These features were built for the developers of a specific client, but if you like the idea of building such a tool for your own project, this article provides an approach for the new breed of Siebel/Web solution designers out there to follow.
Architecture
The above diagram highlights the main components that make up The Harness. Each point will be discussed below.
1. The Harness UI
Provides an interface allowing developers to interact with your Tool.
The UI was hand built using HTML, with jQuery for handling the interactions, and providing the animations.
[Responsibilities]
Provides pretty UI for the user
Pretty prints ECMA Script/XML, displays tabular data
Data entry
2. The Harness Core
The core logic (written in Javascript, with support from jQuery) responds to user actions, orchestrates the work needed to construct requests, execute actions and formats the response before being displayed to the user.
[Responsibilities]
Interface with Storage bridge
Interface with Siebel API through Proxy
Interface with Server libraries through Proxy
Convert between different data representations
Constructs Request from data elements
3. Proxy
Communication between browser and server is managed through a custom proxy, which routes all browser commands to a common entry and exit point. The proxy communicates with the Siebel through a business service invocation, using PropertySets to transport data.
[Responsibilities]
Interfaces with Siebel API
Single point of communication between browser/server
Encode/decode HTML entities
Encodes/Decodes command from browser/server
4. Local data store bridge
The local data store bridge provides a high level API for interfacing with the available storage technologies on the browser. There are many 3rd Party storage libraries that provide this functionality, eg. LawnChair, jsStorage, PersistJS
[Responsibilities]
Interface with lower level browser Storage API
5. Third Party
Third Party libraries are used for syntax highlighting, JS code editor, JSHint, animation
[Responsibilities]
Adds sugar to The Harness
6. Local storage
Local storage is medium for persisting data on the Client. This can be Web SQL, IndexedDB, HTML Storage, Cookies, depending on what is supported on the users browser. The APIs for these storage options are different, so we’ve used the local storage bridge above to abstract the browser implementation from our logic.
[Responsibilities]
Persists client side preferences
Stores historical requests
Save to favourites
7. Browser (Siebel) UI
The Harness is linked to the Siebel UI. This means, we can get the active context of the current browser session, allowing us to implement a business service simulation interface that can work with TheApplication().GetActiveBusObject(). This also allows us to run browser script, or call Open UI’s new API.
[Responsibilities]
Launches The Harness
Interface with Siebel’s browser layer
Interface with Siebel’s active context
8. Server deployed components
This consists of custom script libraries, JAR files, WFs, supporting Business Services, and SRF modifications.
[Responsibilities]
Provide server support for our features
Challenges
Working external to the Siebel repository, and outside the guidelines of classical Siebel development brings some new challenges.
This is the world of the new hybrid Siebel/Web developer, but the lessons learnt here, is also applicable for traditional developers.
Supportability, Maintainability, Persistence, Session Attachment, Access Rights, Deployment
Supportability
When designing a solution, whether it be for Siebel, or for some other application, best practice dictates that we stick to the published supported interfaces.
Undocumented features in Siebel can be an ambiguous bucket.
There are a lot of ‘undocumented’ features in eScript as it is based on the ECMA specification. Siebel provides documentation for its eScript API, but not for all the ECMA scripts features, so projects need to make sound judgements on the use of these features, and have the in-house expertise on standby to support it.
However if you’ve discovered an undocumented user property, remember this isn’t part of any supportable standard. First consider the available alternatives, then choose to use it with caution, but have a contingency plan. User properties have faired quite well in upgrades compared to scripting alternatives.
However, if the solution depends on a hack, be prepared to lose that feature in a future upgrade.
The Harness was built pre Open UI, and has lasted upgrades through 8.1.1.15, 8.1.1.10, 8.1.1.11.
Maintainability
Can your solution be easily extended without too much effort? Your design, should limit the points of configuration, utilise common libraries, and separate configuration from code, this will help with maintainability and extensibility. Spend the time to refactor your code at key stages of its development.
Persistence
Like user preferences in Siebel, the goal of persistence is to remember changes in the state of the browser, and personalize the experience.
As a testing tool, The Harness was built to remember inputs for named test cases, and historical test runs. As a development tool, The Harness had to remember previous actions for recall, review, and reruns.
Cookies may be the first consideration for Siebel veterans who have a side interest in web technologies, but there are better modern alternatives such as HTML storage, Web SQL, Indexed DB. Unfortunately, the implementation isn’t quite standard across browsers, so the solution to this is to use a storage bridge to abstract your interface from the capabilities of the individual browsers.
Keep in mind that these are cached on the clients hard disk, if there is a requirement to have persistence across different machines, then the naturall place for this is on the server. The Harness utilizes a further layer of abstraction on top of the 3rd Party library, allowing it to switch to a different API without costly changes.
Session Attachment/Access Rights
The Harness UI is built from an independent HTML file, and needs to be launched by a user’s action. Considered placements for this launch, can range from the Application menu, from a button on an admin screen, short cut key launch, or via a visibility based icon.
This leads to the question of how to secure the tool from unauthorised access. My mentor once told me, the best security is non-disclosure, if the users don’t know it’s there, they won’t be able to use it!. Although there is some truth to that, The Harness employs a more secure approach by providing access rights through a server side administration screen.
Deployment
The Harness weighs in at more than 10Mbs, with server and client side artifacts. It was important to facilitate ease of installation, updates, and maintenance on the product.
The Siebel web server separates its resources into different locations for SCRIPTS, FILES, 3RDPARTY and IMAGES. Following this pattern makes sense, but it also makes it more error prone to deploy without a proper build process.
An ANT build process was implemented to facilitate deployment of external file resources.
Conclusion
Have your staff have been stuck troubleshooting why a piece of code runs differently in the users object manager, than the WF Object manager?. The Harness can dispatch a chunk of eScript to run on the Server, without costly compiles/deployment.
In a diferent scenario, a developer might be wondering why an XML payload, when transformed into a Siebel Message doesn’t 'upsert'. With The Harness the developer can take the transformed message, or handcraft a modified version, and test out different message structures on the fly, and upsert it without touching tools.
Siebel developers around the world have figured out ways to work smarter, and build competitive advantage through custom tools and processes. It’s in the DNA of every developer, hopefully these ideas inspires designers out there to take the next step to build unique solutions for your clients.