CabMasterPro User Guide
The Automation Server allows a group of AllMasterSoftware 'Designers' to generate reports in the background, and provides facilities for managing the queue of reports.
The AllMasterSoftware 'Designers' operate as normal, and with Automation Server correctly installed, the extra File menu option appears and allows submission of reports in the background. Users select reports in the normal way, but instead of waiting for the reporting to complete, AllMasterSoftware submits a "reporting job" and returns to the user immediately. The user can then continue drawing. The current job is spooled, so the user can change it and do a new set of reports immediately if desired. This works in the same way as Word documents being spooled to a network printer.
By setting up reports with their own default printers and options, a "report job" (i.e. a set of reports) can be printed to one or more printers, and if a printer has multiple paper trays, the job can even have a banner page with a different colour sheet of paper. (This would be user customisable, like any other report.)
A Queue Manager is provided also. This can be run from one or more workstations. It is just like a network printer spool manager. It shows the current state of queued jobs, and lets you delete unwanted jobs.
Here is a block diagram of the Automation Server system and a discussion of the design details of each component. i.e.
These are normal AllMasterSoftware workstations running AllMasterSoftware. Remote reporting is available as a menu option. Internet communication is provided internally, and a request for a group of reports generates an internet packet and sends it to the Report Job Acceptor, which is on the server.
When requesting a background automation job, the designer is presented with a dialog which allows selection of a sequence of reports, with optional repeat counts (allowing a report to have several copies created).
You can also include a plan and 3D print jobs interspersed in the request. And it is also possible to trigger an external task as part of the request sequence. A good example of the use of this is to "execute" a Microsoft Access Database by just specifying the MDB filename. Since Access allows you to include an "autoexec"automatic startup macro - this gives you the power to automate virtually any unattended MS Access operation as part of this queued job.
And other activities can be automated, such as Presentation Pricelist generation, library recalcs, and so on. [There is an advanced tutorial available on Presentation Pricelist Generation which requires some database skills and Developer.]
The AllMasterSoftware user interface also allows predefined automation jobs to be run on the current drawing. Setup a sequence of reports and save as a named report job type. Then to run a set of reports, just select the report job type from a dropdown and hit OK. Everything then proceeds in the background on the server, and control is returned to you almost immediately. A report job could consist of a banner page on coloured paper, followed by printouts of the plan pages 1 and 3, then a 3D printout of pages 1 and 4, then a sequence of 10 preselected reports.
The Queue Manager is the user interface for managing jobs in the queue. It is a web (ASP) page driving the Spooler (COM object, described below). This means that designers anywhere in the office can look at and alter the queue. Access is most easily achieved by a shortcut to start Internet Explorer at this internally accessible controlling URL. The required shortcut is automatically set up when you install AllMasterSoftware Automation Server.
Users can inspect the queue and delete or hold/unhold jobs. The Office Manager can delete, hold and/or reorder the queue. Buttons are provided for moving a selected job in the queue to top, to bottom, up one place or down one place. The traffic lights hold/unhold the selected job(s), and the delete button deletes selected job(s). Multiple selection is allowed.
The status column shows the progress of the currently printing job. In the case shown, report 3 of 7 reports requested is currently printing. The jobs not currently printing just show the total number of reports requested (including repetition counts if any).
This component receives a request from a designer and stamps it with a submitted time. The request consists of :-
The data arrives via an intranet data transfer mechanism from CabMaster. Users need not worry about the details of these request strings - this string is intended to be kept intact and just handed on, eventually reaching the Automation Server.
The Report Job Acceptor lives on the server (as an ASP page) and just hands on the request data packet to the Spooler COM component which adds it to the end of the queue.
The first four commands try to alter the state of the queue. The last three commands (or some equivalent) are just for enumerating the queue for display purposes for the Queue Manager.
Note that with multiple simultaneous requests possible, it is important to identify elements uniquely, not just by a sequence number for requests 2,3,4. Then if two different users start simultaneous activity with one reordering and the other deleting, we won't end up with the wrong elements being deleted. This component does not have any security. It is assumed that by the time a delete or hold request arrives here, we must act on it.
This component does its work by issuing automation requests to Automation Server. Supported requests are: -
In order to issue request 1, it must first copy the "snapshot of current drawing" to the designated data folder, with a filename as jobname.QID. The appropriate support files (tables bitmaps etc) will already be in place, so the document should open with no errors. (If there are errors, they won't be reported here anyway - as a future enhancement, we may add an error report if necessary).
The component runs on the same server as Automation Server, and can obtain the default data folder name from the registry at:- [HKEY_CURRENT_USER\Software\QuisineSoftware\Quisine\Locations].
It is defined by the key DataPath, which if relative will be relative to "ProgramPath". For example a typical setting would be:-
'ProgramPath'='C:\\AllMasterSoftware\\CabMasterPro'meaning that Automation Server will be looking for its data file in the folder
C:\AllMasterSoftware\CabMasterPro\DataHowever, data files can be opened from anywhere.
It then hands over the 'jobname' 'username' and 'report request string' as parameters. This data is all unchanged from when it was handed over to the Report Job Acceptor - it has just sat in the queue for a while. Automation Server will now start printing reports as per this request. Its progress is queried (typically every 10 seconds) to get status information, or aborted if required. Finally, when complete, the document is closed.
Note that this component has no knowledge of what a report request string actually is, or of how to interpret it. It just spools data packets from the report job acceptor, responds to any reorder/hold/delete requests, then hands them on one at a time to the Automation Server which looks after all the reporting/printing.
The Automation Server is an automation enabled extension of AllMasterSoftware. It should be run on a fast dedicated server machine, connected to your company intranet. It accepts requests for report jobs, as described above. It then creates the appropriate temporary data files and sets up the Crystal Report Engine (CRPE) interface so that these reports can be generated exactly as they would be in the designer's original environment.
Reports should be the same as those used on designer's machines so that consistent results are obtained. Also, tables and any other files dynamically referenced when creating reports should be the same. Typically, the Automation Server machine will have a copy of AllMasterSoftware installed exactly as per the designer workstations.
Note that any user can open and request reports on any drawing, so the extra variable 'username' will be handed over to Crystal indicating the current user. This information might be useful for example for a banner report.
In the block diagram, multiple printers are shown. This is just indicating that reports can be preconfigured to go to a designated printer. Thus a given job could produce output on several printers. Also, with appropriate report configuration, a multiple paper bin printer could be used to feed coloured separator banner sheets between jobs. This could be achieved by creating a very simple banner report that pulled the coloured sheet of paper and printed the username, jobname and time in big letters.
The system from the Report Job Acceptor and Spooler Interface down, as illustrated, could be installed on more than one independent automation server machine subject to licensing. The AllMasterSoftware Designer and Queue Manager components would need to select a specific server. This is similar to the way print spoolers work on a network system, and effectively gives good scalability.
There is no provision for automatic load balancing or other high end multiple server features. The need for multiple servers seems unlikely provided a well configured server machine is installed with high performance printer(s) attached.