Skip to main content
Skip table of contents

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:

  1. A site using direct print only.
  2. A site using a local gateway (edge printing)
  3. 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:

Supported printers

https://paragon.konicaminolta.com

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!

  • queue management
  • driver management

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

See Dispatcher Paragon Cloud Client.

(tick)(tick)(tick)

Direct print

Submitted print jobs are printed at MFDs without authentication.
Note: embedded license is not needed for this scenario.
(tick)(tick)(tick)

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.

(error)

Not applicable in this scenario.

(tick)(tick)

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.

See Creating QR-codes and Using the legacy Mobile app.

(tick)(tick)

(warning)

Available with local storage mode.

User identity - cloud providers

See Authentication providers.

(tick)

(tick)

(tick)

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.

(error)

(tick)

(warning)

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.

See SAFEQ Cloud Chrome extension.

(error)

(tick)

(tick)

Direct print not available

Wide Area mobile print

(mDNS, AirPrint)

Users with compatible phones will see the available print queues.

See Configure Wide Area Mobile Print.

(tick)

(tick)

(error)

Mobile App

Use your phone to submit print jobs to the solution and release them.

See Mobility print and Using the legacy Mobile app.

(error)

(tick) 

(tick)

Reporting

(warning) 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.

(tick)

(tick)

(tick)

Using API(tick)

(tick)

(tick)

Basic finishing options

Tray selection, stapling, color/bw, hole punching, simplex/duplex

(tick)

(tick)

(tick)

Finishing options that perform layout altering changes after the job is submitted

  • Using triggers
  • Using API calls
  • At the embedded terminal screen


Change of paper size, orientation and scaling, booklet

(tick)

(tick)

(warning)

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:

  1. 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.
  2. 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(tick)
Mac(tick)
Linux

(error) 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 integrationRequired license

Capabilities and integration method

MFD
  • Core

Direct printing

  • (tick) Can receive print jobs from Dispatcher Paragon Cloud Client
  • (tick) Can receive print jobs from Gateway
  • (tick) Mobile App with direct queue

Pull printing

  • (tick) Mobile app with QR code

MFD with pure cloud terminal

  • Without a local gateway (most common)
  • With local gateway
  • Core
  • Embedded

Direct printing

  • (tick) Can receive print jobs from Dispatcher Paragon Cloud Client
  • (tick) Can receive print jobs from Gateway
  • (tick) Mobile app with direct queue

Pull print

  • (tick) Mobile app with QR code
  • (tick) Full terminal client for print job release and management

MFD with an embedded terminal with a local gateway
  • Core
  • Embedded

Direct printing

  • (tick) Can receive print jobs from Dispatcher Paragon Cloud Client
  • (tick) Can receive print jobs from Gateway
  • (tick) Mobile app with direct queue

Pull printing

  • (tick) Mobile app with QR code
  • (tick) Full embedded terminal client for print job release and management

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.

See Setting up OMNI Bridge.

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 printers26-100 printers101-500 printers501-1000 printers
CPU2 cores/CPU’s4 cores/CPU’s4 cores/CPU’s8 cores/CPU’s
Memory4 GB16 GB16 GB16 GB
Hard diskSSD 64 GBSSD 128 GBSSD 256 GBSSD 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

See Authentication providers.

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:

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
  • Always requires a gateway in the local network
  • GUI version 1 only

  • OMNI/EDGE: login to job list: ~3-4sec
  • OMNI/EDGE: pull print to first page: ~3sec
Canon
  • Always requires gateway in the local network
  • GUI version 1 only

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

  • Cloud: login to job list: ~4-5sec
  • Cloud: pull print to first page: ~10sec
  • OMNI/EDGE: login to job list: ~8sec
HP
  • OxPD variant:
    • Requires a gateway in the local network (not needed for WorkPath)
    • Has version 1 GUI only

  • WorkPath variant requires access credentials and deployment via the HP Command Center 
  • OxPD: OMNI/EDGE: login to job list: ~5-12sec
  • WorkPath: Cloud: login to job list: ~4-5sec
Konica Minolta
  • OpenAPI variant:
    • Requires a gateway in the local network
    • Has version 1 GUI only

  • IWS variant:
    • requires access credentials and deployment via KM Marketplace (or KM IWS deployment tool for Europe & APAC)
  • OpenAPI: OMNI/EDGE: login to job list: ~4-8sec
  • IWS: Cloud: login to job list: ~4-5sec
  • IWS: OMNI/EDGE: login to job list: ~5sec
Kyocera
  • Always requires a gateway in the local network
  • GUI version 1 only

OMNI/EDGE: login to job list: ~4-5sec

Lexmark
  • Always requires a gateway in the local network
  • GUI version 1 only

OMNI/EDGE: login to job list: ~4-5sec

Ricoh
  • GUI version 2 variant requires a local PC with visibility to the printer for initial deployment
  • GUI version 1 and Java variant always requires a gateway in the local network

  • version 1: OMNI/EDGE: login to job list: ~3-5sec
  • version 2: OMNI/EDGE: login to job list: ~3-5sec
  • version 2: Cloud: login to job list: ~4-5sec
Sharp
  • Always requires a gateway on the local network
  • GUI version 1 only

OMNI/EDGE: login to job list: ~5-6sec

Toshiba

Direct print only

n/a
Xerox
  • Always requires a gateway in the local network
  • GUI version 1 only

OMNI/EDGE: login to job list: ~4-5sec

For more information, see Known Issues and Limitations.

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.