Architecture and solution design
Introduction
This document is meant for solution designers who want to understand how the solution works, and in what ways it can be set up. While it is focused on Dispatcher Paragon Cloud hosted by Konica Minolta, other options are also mentioned.
Architecture
In this document, you will find three scenarios represented by three example customer sites:
- A site using direct print only.
- A site using a local gateway (edge printing)
- A site using pure cloud printing
These are the most common use cases, but there are more options for how data flow can be set up.
Note that all of these site options can co-exist in one customer environment.
Data flow and data processing in Dispatcher Paragon Cloud
Data input:
- Print jobs from the Dispatcher Paragon Cloud Client
- Mobile App
- Print to IPP(S) backend
- Chrome browser extension
- Using API
Data processing:
- Printing: additional finishing options can be applied using triggers and automation.
Data output:
- Print jobs are released after authentication, or without authentication, depending on the setup. They can also be held for printing again later.
- Reports on consumption are available in Dispatcher Paragon Cloud Web UI or via API.
Visualization
Customer site A - direct print only
- No embedded license is required for this case. You can add the license later, when the customer is ready to expand the feature set available to users.
- The main benefit is that the customers no longer need print servers. Setting up this scenario is extremely fast - after the printers and users are added to the Web UI, the Dispatcher Paragon Cloud Client automatically displays the correct print queues to all users.
Customer site B with a gateway (edge printing)
- Gateway is HW or SW component. For more information on gateways, see the Gateways section of this document.
- Print jobs can be routed in the following ways:
- Dispatcher Paragon Cloud Client using local storage and connected to the primary server – the most common deployment.
- Dispatcher Paragon Cloud Client using cloud storage and connected to the primary server – when the print jobs cannot be stored locally on the user's PC, for example, because the PC is set up to go to sleep mode shortly, print jobs can be routed to the cloud.
- Dispatcher Paragon Cloud Client using gateway storage and connected to the secondary server (this scenario is not captured in the diagram schematics) – this setup may be useful if you want your devices to only accept print jobs coming from the Gateway. For example, for compliance reasons.
Customer site C - pure cloud
- No local HW is required for the full feature set of Dispatcher Paragon Cloud.
- Print jobs are routed through Cloud servers or using the Dispatcher Paragon Cloud Client with local storage.
Features available in each scenario
Feature | Description | Customer site A (direct print only, no embedded license) | Customer site B (with gateway) | Customer site C (pure cloud) |
---|---|---|---|---|
Supported devices | Supported printer vendors for the individual scenarios: | All listed devices with PDF/Postscript (and some PCL) printing (Brother, Canon, Epson, FujiFilm, HP, Konica Minolta, Kyocera, Lexmark, Ricoh, Sharp, Xerox) | All listed devices with PDF/Postscript (and some PCL) printing (Brother, Canon, FujiFilm, HP, Konica Minolta, Kyocera, Lexmark, Ricoh, Sharp, Xerox) | Fujifilm BI Aip6/7, Konica Minolta e and i series, HP WorkPath, Ricoh SOP (and more to come). |
No more print servers!
| Admin: Configures the locations in the Dispatcher Paragon Cloud Web UI. Users' print queues are created automatically. Everyone is using the same universal print driver. Users: their print queues are synchronized automatically by the Dispatcher Paragon Cloud Client | |||
Direct print | Submitted print jobs are printed at MFDs without authentication. Note: embedded license is not needed for this scenario. | |||
Pull print with embedded terminal (Also known as Print Roaming) | In this scenario, users send a print job to Dispatcher Paragon Cloud and authenticate at any connected MFD to release it. The MFD has an embedded terminal (client) deployed. | Not applicable in this scenario. | ||
Pull Print with QR code + mobile app (Also known as Print Roaming) | This scenario does not require a deployed embedded terminal (no need for a license). Authentication is done using a QR code and the mobile app. | Available with local storage mode. | ||
User identity - cloud providers | ||||
User identity - local Active Directory (LDAP) | Connect to local Active Directory, Novell eDirectory, and IBM Domino. This requires a gateway to be deployed in the customer's environment. See LDAP authentication. | Gateway with visibility to the LDAP is required. | ||
Chrome extension printing | EveryonePrint HCP Extension can be installed on Chromebook or in the Chrome browser to allow direct and pull printing. | Direct print not available | ||
Wide Area mobile print (mDNS, AirPrint) | Users with compatible phones will see the available print queues. | |||
Mobile App | Use your phone to submit print jobs to the solution and release them. |
| ||
Reporting | Dispatcher Paragon Cloud does not act as a print accounting solution and only considers the attributes of a print job at the time of submission, whether it was overall sent as color vs. mono, and the total number of pages sent to Dispatcher Paragon Cloud. Changes in attributes at print time, print errors, or mixed color/mono jobs are not accounted for. See Reports. | |||
Using API | See API documentation. | |||
Basic finishing options | Tray selection, stapling, color/bw, hole punching, simplex/duplex | |||
Finishing options that perform layout altering changes after the job is submitted
| Change of paper size, orientation and scaling, booklet | Only when Dispatcher Paragon Cloud Client with local storage is used. |
Print roaming
Scenario 1
Scenario 2
Scenario 3
Data input - getting the data in
Dispatcher Paragon Cloud Client
Dispatcher Paragon Cloud Client is the most common way for users to submit their print jobs. It contains the Universal print driver. Customers opting for a custom print driver can set up an IPP(s) print queue and select their preferred driver in the configuration process. See Adding IPP print queue manually in Windows and Adding IPP print queue manually in Mac OS.
Print queue deployment
Print queues are automatically created on users' workstations based on the location configured by the administrator. This requires the Universal print driver.
Universal print driver
Universal Print Driver is used for automated print queue creation. See Supported printers.
Delivering the print job
There are two modes of operation:
- Local storage mode – the Dispatcher Paragon Cloud client connects to the primary server via a persistent channel and performs all print and job storage operations locally. Local storage mode requires Dispatcher Paragon Cloud client registration and authorization in the Dispatcher Paragon Cloud server. When a user prints, the jobs are stored on the PC. In case of Citrix or other VDI, it depends on where the Dispatcher Paragon Cloud Client is running, specifically the underlying Dispatcher Paragon Cloud Client service “Dispatcher Paragon Cloud Client Core” runs. Jobs are stored on the Citrix server (where client core service runs), and they will remain there when the thin session is terminated, assuming they have session retention etc configured in their VDI environment.
- Gateway mode – the Dispatcher Paragon Cloud client sends all print jobs to the primary Dispatcher Paragon Cloud server, and has no persistent connection to the server. When the user prints, the jobs are delivered from the PC to the Dispatcher Paragon Cloud server, either primary or secondary gateway, depending on the configuration. Jobs are delivered to MFD using the Document Output service.
Jobs are delivered from the Dispatcher Paragon Cloud Client to the MFD directly if the Dispatcher Paragon Cloud Client can reach the printer. If the Dispatcher Paragon Cloud Client cannot reach the MFD, the job will automatically be routed via the primary Dispatcher Paragon Cloud server to the appropriate Document Output service, which will then deliver it to the MFD.
Supported platforms
OS | Supported |
---|---|
Windows | |
Mac | |
Linux | Planned, beta available upon request |
For more information, see Dispatcher Paragon Cloud Client overview.
Mobile App
The mobile app is available for Android and iOS. It allows users to submit print jobs and release them.
IPP Printing
You can print to the cloud servers directly using IPPS.
See Adding IPP print queue manually in Windows and Adding IPP print queue manually in Mac OS.
Chrome browser extension
EveryonePrint HCP Extension can be installed on Chromebook or in the Chrome browser to allow direct and pull printing.
- Chromebook user authenticates via Chromebook user email address.
- Print queues are synchronized.
Using API
See API documentation.
Data output – printing
Direct printing
The print job is released immediately – users are not required to authenticate at the MFD. At the time of print job submission, users must select which printer they wish to use by selecting the respective Direct queue. Direct queue can route print jobs using local storage (Dispatcher Paragon Cloud Client) or Gateway. User's workstation must have network visibility to the MFD.
Pull printing
Pull print requires users to authenticate at the MFD, ensuring they are authorized to release the print job. The users send the print jobs to the Pull queue and choose where to release them by going to any compatible and connected MFD.
Users can release the print job via the following methods:
- Authenticating at an MFD with an embedded terminal. The available authentication methods are: card, PIN/Short ID, one-time password, username+password.
- Selecting the printer using the Mobile app.
For the fallback route to work, when the primary server is in the cloud and a document is printed from a secondary server in the local network, storage services must be enabled on both primary and secondary servers.
Data output – MFDs, printers
Device integration | Required license | Capabilities and integration method |
---|---|---|
MFD |
| Direct printing
Pull printing
|
MFD with pure cloud terminal
|
| Direct printing
Pull print
|
MFD with an embedded terminal with a local gateway |
| Direct printing
Pull printing
|
Gateways
Other terms for gateway are:
- Secondary gateway
- Secondary gateway server
- Secondary server
- Edge device
Architecture
There are two types of server in Dispatcher Paragon Cloud:
- Primary server – the primary server runs Dispatcher Paragon Cloud Web UI for configuration and management, handles core communication and connection to backend databases and similar master roles.
- Secondary gateway server – the secondary servers are additional server gateways that can run services.
Note that a “server” can take any form. It can be either a hardware or software appliance, or it can be implemented on existing server infrastructure, virtual or physical. It can run anywhere – in the public cloud, private cloud, completely disconnected on-premise, or on-premise connected to a primary in the cloud for central management. Regardless of whether it’s primary or secondary, it can run a single service or all services, depending on the features needed for that particular node. There can be any number of primary and secondary gateway servers, from one individual server to tens of thousands of servers in a very large distributed configuration, without a single point of failure.
Gateways allow document storage and processing to remain local, ensuring document integrity and privacy are maintained. Only the print job’s selected metadata are transferred to the cloud for management and reporting purposes via an encrypted channel. Document content remains secure because it never leaves your premises and thus never reaches cloud components. Data that are not present in the cloud cannot be externally compromised.
When to use Gateway
Gateways are optional. You only need them in the following scenarios:
- Some printers/MFDs do not support pure cloud terminals yet. A local gateway allows you to install embedded terminals at your MFDs.
- When you use local LDAP service (such as Active Directory, Novell eDirectory, IBM Domino), a gateway allows the primary server to access this local user database for authentication purposes.
- You need to keep your print jobs local for security or regulatory purposes.
- You wish to use mDNS printer discovery (Airprint).
- Your Internet connection parameters cannot support the use of cloud terminals with cloud printing because of low bandwidth, high latency, etc.
Gateway is NOT required for:
- Direct print-only deployments (see Customer site A scenario above).
- Direct or pull print with cloud terminal clients (see Customer site C scenario above).
OMNI Bridge
YSoft OMNI Bridge™ is a serverless Edge device, fully managed by Y Soft. It has been built to significantly simplify the deployment of the gateway.
Virtual Gateway
The virtual software appliance is a pre-configured VM image, ready to run on a hypervisor such as VMWare ESX, Xen, Hyper-V or similar Infrastructure-as-a-Service solutions.
Using virtual appliances allows for extremely rapid provisioning and cleanly decouples the operator from the consumer by encapsulating all knowledge of the application within the virtual appliance. Gateway can be installed as a software appliance such as a Virtual Machine (VM) running at any Infrastructure as a Service (IaaS) provider, e.g. Amazon EC2 or Microsoft Entra ID.
See Gateway on Software Appliance.
Other HW Gateways
See Gateway on Hardware Appliance.
Sizing
YSoft OMNI Bridge™
Based on internal testing, we recommend one OMNI Bridge for every 15 printers. However, the customer's print volume, print job mixture, and volume during peak periods may affect the job processing and authentication timeframes. We will refine the recommendation as we gather more information from customer environments.
Other
There are no universal rules for server scaling, as it all depends on the printing volume, and number of users. The following are general recommendations for most scenarios.
1-25 printers | 26-100 printers | 101-500 printers | 501-1000 printers | |
---|---|---|---|---|
CPU | 2 cores/CPU’s | 4 cores/CPU’s | 4 cores/CPU’s | 8 cores/CPU’s |
Memory | 4 GB | 16 GB | 16 GB | 16 GB |
Hard disk | SSD 64 GB | SSD 128 GB | SSD 256 GB | SSD 512 GB |
Hosting
Dispatcher Paragon Cloud is designed to offer several hosting options depending on which business model is being used. Dispatcher Paragon Cloud can accommodate service providers having their own data center, service providers having no data center, and also an on-premise private cloud solution for customers with high-security requirements.
Hosted by Konica Minolta
The platform can be installed in a Konica Minolta data center. As a partner, this gives you the ability to provide a hosted print solution without investing in a data center. You have full control of your customers and businesses through the Dispatcher Paragon Cloud Web UI as if Dispatcher Paragon Cloud was installed in your own data center.
Regions
Y Soft’s data center infrastructure is available in the USA, Canada, The European Union, the UK, Singapore, and Australia regions.
Other options
Refer to this section or contact Konica Minolta for more hosting options.
User identity
The following options are available:
- LDAP authentication
- Requires Gateway to enable the network communication
- Microsoft Entra Authentication
- Google Workspace Authentication
- OKTA Authentication
- Auth0 Authentication
- PingID Authentication
- External card provider API authentication
Single Sign-on
The following Single Sign-on options are available
- Microsoft Entra Single Sign-On
- Okta Single Sign-On
- PingId Single Sign-On
See Single Sign-On.
Availability, security
Cloud services - hosted elsewhere
High Availability considerations for non-Konica Minolta hosting options are not in scope of this document. Refer to server deployment guides:
- Deployment documentation: Server Installation in custom deployment scenario
- Primary server clustering: Configure a primary server cluster
Security
See Security and privacy.
Limitations
- Modifying finishing options after the print job was sent is not available when the print job is downloaded to the pure cloud terminal. When cloud terminals are configured for cloud, it only works when local client storage is used.
- Reporting accuracy - the solution only considers the attributes of a print job at the time of submission, whether it was overall sent as color vs mono, and the total number of pages sent to Dispatcher Paragon Cloud. Changes in attributes at print time, print errors, or mixed color/mono jobs are not accounted for.
General Limitations of the embedded terminals
Vendor | Notes / Limitations | Reference responsiveness (OMNI/EDGE: embedded in the local 1Gbps network. Cloud: public 100Mbps up/down stream network) |
---|---|---|
Brother |
|
|
Canon |
| OMNI/EDGE: login to job list: ~4-5sec |
Epson | Direct print only | n/a |
FujiFilm | Requires a Windows PC with visibility to the printer for initial deployment |
|
HP |
|
|
Konica Minolta |
|
|
Kyocera |
| OMNI/EDGE: login to job list: ~4-5sec |
Lexmark |
| OMNI/EDGE: login to job list: ~4-5sec |
Ricoh |
|
|
Sharp |
| OMNI/EDGE: login to job list: ~5-6sec |
Toshiba | Direct print only | n/a |
Xerox |
| OMNI/EDGE: login to job list: ~4-5sec |
For more information, see Known Issues and Limitations.