System Setup / Plugin Customization / Plugin Configuration [SET062]
The current DATASCOPE WMS Core printing is managed by a built-in Crystal Report-based engine. This process allows for custom Report (RPT) files to be created for the system's specific printing parts. These are then populated using a dataset and spooled to the printers configured within the different modules.
This does allow for a level of customization within the RPT files; however, customers are still hooked on using the Crystal Engine. Some of the limitations of this are speed and stability within the printing engine. Printing thousands and thousands of labels can be quite heavy on Crystal and slow in some cases.
To resolve the above mentioned problem statement, the most simple and flexible solution it is to introduce a DATASCOPE WMS Plugin for the core printing process in the system. This means that if configured, the system will call this new plugin, and it can then manage the printing in whichever way it likes.
| Info |
|---|
Release notes 24.1 (Ticket # 8326) - A new Printing Plugin has been developed. |
| Info |
|---|
If you don’t like reading, you can watch the video. |
| Panel | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
None None |
Try it!
Type | Plugin Name | Interface | Module | Linked Action |
Printing | Core Printing | ICorePrinting | Core Printing |
The plugin works the same as all existing plugins, if its configured it will be called, if not configured the existing logic will be applied. Thus, if configured the core system will expect the plugin to manage the printing and nothing will be sent to the Crystal Engine.
To configure this plugin:
From the Main Menu, browse to System Setup / Plugin Customization / Plugin Configuration
Select Core Printing Plugin from the Plugin Name drop-down.
Select ADDfrom the Action drop-down
Enter a Display Name (i.e. Printing)
Select the applicable DLL - in this case it will be Print.dll
| Info |
|---|
All the Plugin .DLL files are located on the DATASCOPE WMS server under C: / Program Files (x86) / DATASCOPE / DATASCOPE WMS WebAPI / Plugins. . Refer to https://datascopewms.atlassian.net/wiki/spaces/TG/pages/109051919/What+is+needed+to+work+with+Plugins#Location-of-plugin-files . |
Select Save to save the configuration.
This plugin will now be configured all Core Printing functions (buttons).
The return type of the plugin will be a string. The string will have three options: True, False or Error. This will allow the the plugin to tell the core system to print the report, not print the report or return an error message.
If the plugin returns a “True” = the document has been printed and the core system DOES NOT need to print anything.
If the plugin returns a “False” - the document has NOT been printed and the core system MUST print the document.
If the plugin returns an “Error” - the message will be thrown in the core system and be displayed to the Operator.
This logic will give the plugin additional function that if can handle some of the printing but not all. So if the 3rd party developer only wants the plugin to handle Track ID Reprints, they can code it in such a way that when called for any other print job it simple returns a False, indicating that the core system should continue to print the document.
The new plugin to be created and located within the existing core print processed in the Webservices and WebAPI printing processes.
The existing printing is contained in a single location within the Webservices and WebAPI print processes and this is the most logical point of entry for the Plugin to be placed for a minimal invasive implementation.
The existing plugin “template” should be used where the plugin is only loaded if it is configured in the tables. The following parameters will be supplied to the plugin and defined in the interface:
pBaseProperties - This is standard on all plugins and business objects and provides the developers with some basic information like Company ID, Operator, GUID etc for use in the plugin as needed.
pSystemAction - This is the System Action that is linked to the print job being processed. This is a key field as it indicates the “type” of print that is happening. This is the field that the developers can use to determine if they are handling the print or not in the case not everything is being printed by the plugin.
pWarehouse - This is the Warehouse code linked to the print job. In the core system this along with the System Action is used to determine the Printer and/or report name.
pReportName - This may or may not get used but will contain the name of the core configured Crystal Report template file that would be used by the core if it were to be printing.
pData - This is the RAW data that the system would have used to bind to the report being printed. This can be used or not used as the developer sees fit. There is no specific structure to this and if the developer were to need this they can dump it out using the plugin first. This changes from system action to system action.
pNoPages - This is the number of pages that the core system was requested to print for the particular print job being processed.
pPrinterName - This is the name of the Printer that the core system would have printed the print job to. This will be a network printer, installed on the WMS Server.