Showing posts with label The Harness. Show all posts
Showing posts with label The Harness. Show all posts

The Harness: Use Cases


The Harness is a modern Siebel development tool, that was built to help a customers Siebel development team to maximize their efficiency, by reducing the amount of time that is lost through the build, compile, and unit test cycle. It was developed off the necessities of integration development, and evolved from some essential use cases.

The Harness is deployed as part of the standard developers tool set, and is currently available to all integrators, configurators and production support staff, along side other necessary tools such as database clients, XML/code editors, source control tools.

It has been about two years since the first alpha version was built, and it has matured into a product that is used for development and production support.

The Harness was originally introduced to readers, in The Harness, and subsequently in The Harness Case Study, in this article, we go through the use cases, and provide videos walk-throughs of common usage scenarios.

Use Case 1 - Expression testing


Siebel expressions can be found universally in Siebel, but they can be notoriously difficult to troubleshoot.

For complex expressions, it is easy to make a mistake, leave out a bracket somewhere, or mis-spell the reference to a field or function, and when Siebel expressions are configured incorrectly, they famously error out silently. This adds significant overhead to the development process, because each change has to be iteratively compiled into the SRF.

The Harness provides an Expression module, that allows developers to simulate expressions in real time

The Harness VS Vanilla Siebel


  • Provides the ability to simulate Siebel expressions in real time
  • Supports documented Siebel expressions
  • Supports undocumented Siebel expressions
  • Supports BC Field, and WF property notations


  • Expressions cannot be simulated in Siebel
  • Use Case Video: Expression Tester - Fun with Timestamp
    https://www.youtube.com/watch?v=JNH6CnGbAGU

    Use Case Video: Expression Tester - Lookup Function
    https://www.youtube.com/watch?v=w26Ae9Tnfjc

    Use Case 2 - Run eScript on the fly


    One of the pain points of Siebel development, is the need to make iterative changes to eScript, which requires the developer to compile the changes into the SRF, launch the thick client, and execute the code to build and unit test code. This is another task that adds significant development overhead.

    The Harness allows developer to build and test eScript on the fly.

    The Harness VS Vanilla Siebel


  • Write, test eScript on the fly using a web browser
  • Supports ST and Non ST Script engine
  • Supports custom script libraries
  • eScript can be run locally, on the server, or asynchronously
  • Code indenting, highlighting, JS code hints for Non ST engine
  • Library feature integrates with JSDoc comments for documentation
  • Code can be generated from predefined templates
  • Can be used to inspect runtime object variables


  • Traditional eScript needs to be compiled into the SRF, re-triggered, and retested after each change
  • Developers also have the option of using the notepad like client side business service editor
  • Use Case Video: Script Module - Run eScript on the fly
    https://www.youtube.com/watch?v=jERcYcguYXA

    Use Case Video:  Script Module  - Library Search
    https://www.youtube.com/watch?v=KNaSWYiIAfo

    Use Case 3 - A modern Business Service simulator 


    The BS SIM module provides the ability for developers to simulate business services with current application context.

    It also provides modern features such as auto complete, and input property helpers, that makes testing Siebel business service behavior much more fluid.

    The Harness VS Vanilla Siebel


  • Auto-complete data for business service names, and business service methods.
  • Auto-complete data for business service input arguments, workflow process inputs, and BRP Process inputs
  • Supports Siebel expression notation
  • Converts XML into SiebelMessage/PropertySet/Hierarchy, as an input into the service
  • Simulate any business service with current application context
  • Can be configured with project specific form prefills
  • Test cases can be saved, restored and persisted between sessions


  • Using Business Service Simulator the developer has to click new record, open the Pick applet, and use a wildcard search to get the service name, or method
  • Similarly for input property name/value, the developer has to click new record, open the child applet, click new record, and enter in a each name/value pair
  • No input property argument is provided
  • Complex hierarchies has to be manually constructed, or shifted from the back of another business service invocation
  • Simulation only works under the Business Simulator BO
  • Test cases history is not available in the UI, it has to be saved/restored from a file system location.
  • Use Case Video: BS Sim Module - Autocomplete Fields
    https://www.youtube.com/watch?v=xdZKsg4T1kQ

    Use Case Video: BS Sim Module - Form Prefill
    https://www.youtube.com/watch?v=Y0lsRU9hNEs

    Use Case Video: BS Sim Module - History, with eScript generation
    https://www.youtube.com/watch?v=umfnsBAGaXs


    Use Case 4 - Manipulating the data layer


    The BC module provides a tool for the developer to interrogate the configuration behind the current view, as they navigate the Application. The Harness automatically detects the application context, and pre-fills the necessary the form fields to manipulate the current record.

    This module a provides developers with the ability to create, update, delete, and query for data behind the UI.

    The Harness VS Vanilla Siebel


  • Detects UI context, and allows CRUD operation with a web UI
  • Supports non UI context objects
  • Tools configuration is exposed through the BC module UI


  • Developers have to use a combination of "About view", a SQL tool, and Siebel Tools
  • Use Case Video: BC Set Readonly Field
    https://www.youtube.com/watch?v=mu5hJvqyl9I


    Use Case 5 - Learning the Open UI API


    The OUI module provides the Open UI developer with a web UI, that integrates with the Siebel session, displays information about the current Screen, View, BO, BC, Applets, and controls, and allows developers to drilldown into the OUI API.

    Commands can be executed against the Siebel session using the inbuilt console, and the auto-complete box allows the developer to quickly search through multiple levels of API name spaces, and custom libraries.

    The Harness VS Vanilla Siebel


  • About View with object inspection
  • Learn the Open UI API by browsing on screen objects.
  • Console with access to the Siebel session
  • Indexes and provides auto-complete search for multiple script libraries
  • Automatically probes and displays information, from methods that return data


  • Developers can manually look at source code, or memorize documentation
  • Open UI developers still have to use About View", and lookup the corresponding configuration in Tools
  • Use Case Video: Open UI API Browser
    https://www.youtube.com/watch?v=n-CLyrc_YA8


    Other modules


    MQ/HTTP Module

    The Harness originated from this humble module. The MQ/HTTP module is an essential module for Siebel EAI/middleware developers. It provides a real time interface for sending/receiving messages across message transports. This specialist module provide important prefills on transport parameters, and message templates, that can be used to quickly setup data, and interrogate interface behavior, with XML aware syntax highlighting.

    IO/Msg Module

    The IO/Msg module is another essential tool for Siebel EAI/middleware developers, that allow messages to be generated, inspected, upserted/inserted/synchronised and converted on the fly.

    Server Health Module

    The Server Health modules probes the server to provide important information such as the machine that the session is connected to, server disk, memory, and CPU utilization. This has been found to be useful in pin pointing problems in resource constrained environments.

    FAQs


    Does it work with HI/Open UI?

    The Harness was originally designed to work in HI, and has since been ported over to Open UI.  It has been tested against HI 8.1, OUI IP2012, IP2013, IP2014, IP2015

    Does it replace Siebel tools?

    No. The Harness augments Siebel Tools, however depending on the role of the developer, they could spend a significant part of the day in The Harness testing interfaces, and writing unit test cases, reverting to Tools to create the necessary foundation objects.

    How long does it take to build such a tool?

    2 months to build an alpha version from scratch.

    What kind of skill set do I need to build this tool?

    Siebel professionals with expertise in eScript, Web professionals with strong JS, UX, and Java is also helpful

    I would love to have it as part of my collection, can you send me a copy?

    Unfortunately for third party Siebel tool collectors, The Harness is an internal product.

    Where can I download it?

    The Harness cannot be distributed in its current form.

    Can I trial The Harness?

    The Harness doesn't have a trial mode

    Can I take this tool onto my next project?

    The Harness contains specific customer code, and integrates tightly with a client library. Key parts of the program has to be ported, and a suitable core library has to be established, for it to be used on a new project.

    Contact me on Linkedin, if you are interested in knowing more.

    The Harness Case Study

    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.

    The Harness

    Siebel Development Lifecycle

    Putting on my Siebel developer hat, I think to all the wonderfully painful hours spent, on all the small, yet numerous time consuming tasks that litter the life of a Siebel professional.

    Compared to other software development tools, it is easy to over simply Siebel development by, using wizards, with a bit of drag and drop, sprinkling a few user properties here and there, we can build a basic application without a single line of code. But in the real world, things are much more complex, and it can take a multitude of steps, plus a bit (or a lot) of frustration to get a basic building block established

    A simple example is testing Integration Objects. The following link from Siebel Bookshelf describes this process

    http://docs.oracle.com/cd/E14004_01/books/EAI2/EAI2_IntObjs_CreatingMaint11.html

    After creating your IO you must:

    1. Create a Workflow
    2. Create an EAI Siebel Adapter step with all the required inputs
    3. Create an EAI XML Write to file step with required arguments
    4. Launch a WF simulation session (and pray that that it starts)
    5. Execute the WF steps
    6. Open up windows explorer
    7. Inspect the output file for the needed results

    How about testing a Dot notation expression to retrieve a value from a SiebelMessage?

    1. Create a Workflow
    2. Create a property to store the result
    3. Create an EAI Siebel Adapter step to query an IO
    4. Create an Echo step and provide the Dot notation
    5. Launch a WF simulation session
    6. Execute the WF steps
    7. Inspect watch window for the result

    Another example, is testing eScript. A typical life cycle of a Siebel coder runs like this.

    1. Find a suitable Event Handler or BS
    2. Write code
    3. Compile code
    4. Re launch thick client
    5. Trigger code
    6. Inspect results
    7. Goto step 2 and repeats until it works

    Compiling, waiting, executing, and unit testing code iteratively is time consuming and also depressing.

    These tasks provide a glimpse into the daily toils of a Siebel developer, and illustrates how many small tasks stack up, easily filling up a days work.

    The Harness

    Have you wondered if life can be better? Many developers over the years have come up with utilities that make life easier, tools that search the repository, tools that perform script or config reviews, tools that load LOVs, some experts have even come up with tools that generate browser script in 5 seconds!



    The Harness, is the accumulation of years of pondering the Impossible in Siebel. It is a tool that aims to compliment Siebel Tools, and even fills in some of the shortfalls of the Siebel product.

    The Harness comes packed with a suite of testing, troubleshooting and development capabilities rolled up into a UI with a modern interface. And where Siebel Tools is restricted to your local machine, the Harness was designed to be launched from any thick or thin client connection, which allows it to be useful in even in test and production environments.

    The aim of The Harness is simple, to make every developer more productive.

    Want to test some eScript that you just dream't of?

    Just open up The Harness, start typing in the in-built code editor with, syntax highlighting, code indentation, and code hints, or choose from a defined set of templates, then click a button to execute the code and see the results immediately, without compiling.

    Want to see what your newly created IO looks like in XML, Hierarchy or PS?

    Just provide the IO name, Id, click a button, and see the preview in real time, with XML aware syntax highlighting.

    Top 10 Features

    1. Run 100% eScript without compiling
    2. Run eScript locally, on the Server, or dispatch it to run on the Server Asynchronously without compiling
    3. Simulate any BS any where in the Application with context!
    4. Test Dot notation expression for any IO
    5. Send/Recieve MQ messages on the fly
    6. Generate XML/Hierachy/PropertySet output for any IO
    7. Convert from XML to PS/Hierarchy/SiebelMessage on the fly
    8. Run DOS commands from the browser
    9. Advanced About View, with table information
    10. Peek at runtime BusComp variables

    In future articles, we'll go through the above list, and show how the Harness can make the lives of your developers more productive, and less depressing. We also take a look at the architecture behind the tool and delve into the design of its features.

    For the time being, here's a sneak peek at one of the early alpha versions.

    http://www.youtube.com/watch?v=hGYgHqT26rU

    Note: The Harness was built for a client with custom integration requirements. It has since been expanded into a general developers tool.