Frequently Asked Questions
This Frequently Asked Questions (FAQ) section answers the most commonly asked questions about WorkScript.
Q1. How long does it typically take to rollout a working implementation of WorkScript?
Q3. How many users can the WorkScript system support?
Q8. Typically, how often are WorkScript software upgrades released by Wordware?
Q9. What training does Wordware offer for WorkScript?
Q11. How are logon credentials passed from the web-based client to the invoked application?
Q13. What needs to be configured to invoke the correct application?
Q14. How does the business process reporting application know when a business process is completed?
Q17. How are people involved in the workflow process notified of a task that requires action?
Q1. How long does it typically take to rollout a working implementation of WorkScript?
A1. Most implementations can be operational within two weeks but this depends on the number of processes that need to be loaded into WorkScript. The system allows immediate use of a process as soon as it is loaded so that the system is operational as soon as the first process is loaded. Additional processes can be added at any time and these also become operational immediately. The system encourages progressive build up and release of your organisational processes rather than taking the "big-bang" approach.
Q2. What happens if my company does not have all of its policies and/or procedures documented in a format that is accessible by WorkScript?
A2. Wordware has the experience and tools to assist you in properly documenting your organisation’s polices and procedures.
Q3. How many users can the WorkScript system support?
A3. This is a difficult question to answer because it varies with each operating environment. The number of users that can be supported varies with the computing capacity of the web server machine and therefore the user load that it is capable of supporting.
Basically, the maximum number of users can be increased by increasing the number of web servers to scale the system to many tens of thousands of users.
Q4. My organisation has many office locations geographically dispersed. Can WorkScript be used to link our offices together?
A4. Access to the WorkScript system can be by LAN, WAN, VPN, Internet, or dial-up line. The very low additional overhead that Workscript introduces has only a marginal impact on the speed of the connection. If you can currently access your company’s network remotely then WorkScript will work on your network.
Q5. What operating environment does WorkScript require and what are the hardware specifications that it needs?
A5. From the user’s perspective WorkScript is simply accessible using a browser such as Internet Explorer. The core software runs on a web server with MS Windows NT4/200x and IIS. The database is MS SQL7/SQL200x or any other ODBC-compliant database.
A typical server machine would be a Pentium 4 / 3GHz CPU, 2GB RAM, 40GB hard disk and 10/100 Mbps network interface card.
Q6. Does my organisation have to call on Wordware every time that a change to one of our organisational processes is required?
A6. Absolutely not! The WorkScript software design philosophy was driven by a need to make the system totally user configurable and maintainable. Wordware is available to support you if you need help in making process changes but this is purely at your discretion.
Q7. What expertise or qualifications/training do I need to have to be able to create and maintain processes in Compass WorkScript®.
A7. Wordware’s training course for WorkScript covers in detail, the functionality available in the system. The only pre-requisite to the two-day training course is a knowledge of process design, that is, how your organisation develops and documents its operating processes.
No software programming skill is required in using the system to capture business processes or to make changes to processes. A process-owner maintains the system using an intuitive drag-n-drop interface whenever they need to modify an organisational process.
Q8. Typically, how often are WorkScript software upgrades released by Wordware?
A8. The on-going development cycle usually allows Wordware to release a software upgrade 1-2 times per year. At least one major upgrade can be expected within any 18-month period.
Q9. What training does Wordware offer for WorkScript?
A9. Wordware offers a variety of training courses some standard and some tailored to client specifications. We are happy to design a training program that will suit your organisational needs.
The normal training programs are: (1) a two-day course for system administrators and process owners, (2) a two-day course for technical staff and software administrators, (3) a half-day course for end users, and (4) a one-day "train-the-trainer" course.
Q10. What is the CAL and how does Compass WorkScript link in with my favourite desktop applications and the tools that I use everyday?
A10. 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.
Q11. How are logon credentials passed from the web-based client to the invoked application?
A11. 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.
Q12. 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)?
A12. 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 LetMe 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.
Q13. What needs to be configured to invoke the correct application?
A13. 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.
Q14. How does the business process reporting application know when a business process is completed?
A14. 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.
Q15. What reporting capabilities exist to measure whether any of the process step related content is viewed and by whom?
A15. 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.
Q16. What needs to be done to define new workflows? Does the workflow engine support parallel workflow paths and conditional joins?
A16. 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.
Q17. How are people involved in the workflow process notified of a task that requires action?
A17. 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.
Q18. Can launch and expiry dates and times be set per content item and will the system automatically perform the launch and expiry?
A18. At each step there is a LetMe 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.
Q19. 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)?
A19. Currently WorkScript integrates with NT Security.
It runs on Windows NT 4.0 or Windows 2000/2003 Server running IIS.
It currently supports MS SQL Server however our ORACLE implementation and it will be available soon.
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.