Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

System Setup / Plugin Customization / Plugin Configuration [SET062].

A built-in Crystal Report-based engine manages the current DATASCOPE WMS Core printing. This process allows 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 allows for customization within the RPT files; however, customers are still hooked on using the Crystal Engine. Some of its limitations are speed and stability within the printing engine. Printing thousands of labels can be heavy on Crystal and slow in some cases.

To resolve the problem statement, the most simple and flexible solution 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 whichever way it likes.

Release notes 24.1 (Ticket # 8326) - A new Printing Plugin has been developed.

If you don’t like reading, you can watch the video.

None

Try it!

Type

Plugin Name

Interface

Module

Linked Action

Printing

Core Printing

ICorePrinting

<various>

Core Printing

Overview of the Source Code

The plugin's source code is provided within the DLL file and can be changed for additional or different logic.

 Note: All the plugins. DLL files are stored on the DATASCOPE WMS server under C: / Program Files (x86) / DATASCOPE / DATASCOPE WMS WebAPI / Plugins.

 The plugin's return type will be a string. The string will have three options: True, False, or Error. This will allow 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 an additional function that can handle some of the printing but not all of it. So, suppose the 3rd party developer only wants the plugin to handle Track ID Reprints. In that case, they can code it so that when called for any other print job, it simply returns a False, indicating that the core system should continue to print the document.

The new plugin will be created within the existing core print process in the Webservices and WebAPI printing processes.

The existing printing is contained in a single location within the Webservices and WebAPI print processes. This is the most logical point of entry for the Plugin to be placed for a minimally invasive implementation.

The existing plugin “template” should be used where it is only loaded if 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 linked to the print job being processed. It is a key field as it indicates the “type” of print that is happening. The developers can use this field to determine whether they are handling the print or not if the plugin is not printing everything.

  • pWarehouse—This is the Warehouse code linked to the print job. In the core system, this and System Action determine the Printer and/or report name.

  • pReportName—This may or may not get used, but it will contain the name of the core-configured Crystal Report template file that would be used by the core if it were to print.

  • pData—This is the RAW data that the system would have used to bind to the report being printed. The developer can use or not use this as he or she sees fit. There is no specific structure to this, and if the developer needs it, they can dump it out using the plugin first. This changes from system action to system action.

  • pNoPages - This is the number of pages the core system requested to print for the particular print job being processed.

  • pPrinterName—This is the name of the Printer to which the core system would have printed the print job. This will be a network printer installed on the WMS Server.

Building the Plugin

For more information regarding building the plugin, refer to the high-level overview on how to build a basic plugin - Developing your own plugins

  • No labels