Technical Details
WorkScript is designed for enterprise-wide rollout, where users access the Wizards through any web browser. There is no special software required on the user’s machine. The user operating environment is typically Microsoft Windows and Office and the web server operating system is Windows 200x Server running IIS.
The WorkScript platform is a MS DCOM/SOAP-based software platform that enables companies to quickly transform business processes into flexible, distributed, wizard pages accessed and managed over intranets, extranets, and the Internet.
|
|
WorkScript makes a real difference to your organisation's quality, performance and bottom line by:
- Reducing training, support and rework costs by up to 90%.
- Increasing productivity by accelerating performance by up to 30% overall.
The WorkScript Wizards also provide the detailed operating metrics and reports needed by management to monitor the performance of their business processes in real-time.
Frequently Asked Technical Questions
/
Q1. What is the AppLauncher and how does WorkScript link in with my favourite desktop applications and the tools that I use every day?
WorkScript uses a small plug-in called the AppLauncher. Briefly, the purpose of the AppLauncher is to launch PC-based applications on the client machine. This is necessary because, for security reasons, you cannot launch standard PC-based applications from a browser.
In addition to launching PC applications, the CAL will download any files used by the application (i.e. Word documents, ini files, etc.) from the server and if required upload the document back to the server when the user has finished.
On installation of the AppLauncher, the user (or administrator) must set-up the WorkScript Business Services proxy so that the AppLauncher can communicate back to the server. This is as simple as entering the server name if communicating via DCOM, or the server web address if communicating via SOAP.
When the AppLauncher is invoked it is passed the current user’s session key from the browser; the AppLauncher uses this to validate that the user is logged in and valid before opening the application. The purpose here is to make sure the user is not visiting a third party site with a fictitious session key and malicious link.
Note on the AppLauncher vs. traditional Portal access: the AppLauncher is used to integrate existing PC based applications with our process web portal interface. "Traditional" (use the word lightly) portals require the applications that they aggregate to have a web interface or for some web view of the system to be developed.
Q2. How are logon credentials passed from the web-based client to the invoked application?
When the user logs into WorkScript a unique session key is generated. This session key remains valid until the user logs off or until the user has been inactive for greater than 10 minutes. (Note: if the user is logged into WorkScript, the browser will keep the session alive without the user having to interact with it, as long as the WorkScript application is still displayed in the browser). A unique key is generated each session (i.e. keys are not reused).
When the AppLauncher is invoked, the browser passes the session key to the AppLauncher along with state information such as the current task id. This can be used to call through to the WorkScript Server to retrieve whatever information is stored within WorkScript. (Note: all WorkScript APIs require a valid session key).
By default we do not store user credentials for other systems. When the other system is invoked the user must enter their user credentials for that system to gain access as they normally would.
Q3. Is the AppLauncher aware of the existence of open application user sessions and is it aware of the state of these (e.g. running, updating, idle etc)?
AppLauncher is aware of running applications if it invoked them. AppLauncher creates a lightweight background thread for each application and monitors its completion.
This is how the AppLauncher knows when to upload documents back to the server. For example, the user selects a Let Me that downloads a Word document and launches Word; once the Word document is closed by the user, the AppLauncher will upload it back to the server without the user having to worry about it. If the program as already running and it is launched again, the AppLauncher will display the current instance of the program.
Q4. What needs to be configured to invoke the correct application?
The AppLauncher works by launching programs via the command-line. Therefore the command line needs to be identified in the Process Map Designer. If files are to be used with the application then these need to be registered with the system and uploaded to the server.
For more complex systems we provide (or create if it doesn’t exist) Helper Applications. These are command-line programs that are launched by the AppLauncher and handle any specific integration behaviour between WorkScript and the system.
For example, we have an SAP Helper App that when launched reads the ini file, passes and navigates the SAP GUI screen to the specified transaction screen and optionally pre-populates or captures fields in the screen with data from WorkScript.
The first time the user launches the SAP Helper App it launches the SAP GUI and the user is required to log in. Subsequent requests reuse the same session.
These Helper Apps are written to be generic (i.e. configured by a simple ini file) and generally take only a few days to implement and test.
Q5. How does the business process reporting application know when a business process is completed?
All task-related data is stored in the WorkScript database, which can be accessed by any reporting tool through ODBC.
Alternatively WorkScript has a COM and SOAP (Web Services) API into WorkScript that can be called to access the data. All APIs return the data as XML formatted strings.
WorkScript also has an event engine that can trigger an external handler to generate notifications.
Q6. What reporting capabilities exist to measure whether any of the process step related content is viewed and by whom?
All iterations of each process step are recorded in the database. This includes the time started, completed, by whom and what the outcome was.
WorkScript does not currently record what content was viewed while performing the step, although this can be obtained from web server logs and reported on using a reporting tool such as Crystal Reports.
Q7. What needs to be done to define new workflows? Does the workflow engine support parallel workflow paths and conditional joins?
The WorkScript Process Map Designer uses Microsoft Visio as the drawing engine. Therefore creating WorkScripts is as easy as drawing a flow chart.
The system caters for parallel flows and merging. On merging, the outcome of all parallel flows is used to calculate the subsequent path.
Timeouts and escalation conditions can be set on parallel flows as well as normal processes.
Q8. How are people involved in the workflow process notified of a task that requires action?
If the user has an email address defined and a task requires their action, they receive an email containing information about the task and a hyperlink that will take them into the system and directly to the active step of the task.
Escalation conditions can be assigned to the process so that if the task is not actioned in a specified timeframe the user, manager, or other user can be notified via email.
An alternative action is for the task to be escalated to another priority queue. Multiple escalation conditions can be assigned to the same task.
Q9. Can launch and expiry dates and times be set per content item and will the system automatically perform the launch and expiry?
At each step there is a Let Me resource which is the application that is to be used for the step.
This can be set as a prerequisite for the step, so that it must be actioned before continuing and it can also be set to auto launch so that the user does not need to manually launch the application.
This further speeds up the process for experienced users.
Q10. What infrastructure components are supported from a database, operating system, web server, application server, LDAP, single sign-on perspective and integration technology perspective (e.g. MQ Series, MSMQ, JSM, etc)?
Currently WorkScript integrates with NT Security.
It runs on Windows NT 4.0 or Windows 2000/2003/2008 Server running IIS.
It currently supports MS SQL Server 2005/2008 AND ORACLE 9i.
WorkScript uses MSMQ for its own event processing and publishes its APIs via COM and SOAP (Web Services).
All APIs return data in XML formatted strings.
Email is sent via standard SMTP.
|