Let's Talk
Papyrus Adapters and Typemanagers

Simplified Integration, Interoperability & Connectivity

Papyrus solutions interface with any business system, as well as back-office users, by leveraging Service-oriented Architecture (SOA) to flexibly integrate via loose coupling and configuration without without hard-coded interfaces.

Any system, application or database that supports at least one of the most common interfaces and protocols provided by a range of Papyrus SOA Adapters and Type Managers can be simply and easily integrated to ensure complete interoperability and connectivity:

  • Online channels/portals - Web Services, SOAP, HTTPS
  • Email/messaging – SMTP, POP3, MAPI, IMAP, SMS
  • Mainframe - JES 2/3 & CICS, MQ
  • Databases - Oracle, DB2, MS-SQL, ODBC
  • Business Application integration - SAP, Social, Mobile-REST
  • Java, .Net, MQ-Series, FILE, XML, FAX, VOIP, SNMP, LDAP, CMIS
Omni-Channel Integration

Overview

Papyrus Software enables enterprise application integration for your business communication and document systems with two types of connectors to meet virtually any need you may have:

  • Adapters for loose coupling of business application data with document application in a platform- and compiler-independent format
  • Typemanager for database-independent interfaces and SQL support

Papyrus Adapters help minimize the cost and risk of interfacing with outside systems by foregoing the limitations of commonly used APIs. The Papyrus EAI approach not only prevents a significant amount of custom programming but also ensures that the leading system can continue to monitor the process without passing control to a third-party application or system.


About Adapters

A broad variety of Papyrus Adapters connect the document system with vital business application data from almost any major legacy or mainstream system or application. These platform- and compiler-independent connectors drastically reduce the amount of time and effort required for interfacing with applications that span multiple systems and require the passing of documents and data between these systems.

Basic principle of an adapter-receiver setup

An adapter acts as a translator that waits for an event to take place. When such an event occurs, The RECEIVER will use its MATCH definitions to find a TEMPLATE in its library which is instantiated and filled according to the TYPE PROPERTIES. In this flexible manner, defining how the adapter reacts to a certain event requires no programming compiling adapter programs or the need to distribute them.

An adapter is the parent object of an adapter/receiver setup. All adapter templates/instances are derived from a single adapter class in the Repository. To be operable, only the Type attribute of the adapter has to contain a string that denotes the receiver type. This string is used in the later on described match criteria (= type properties) to identify the adapter.

The following 12 Adapters are now available to meet your unique integration needs across 11 different operating systems.


Adapter/File

The File Adapter/Receiver monitors a predefined directory for files with particular naming convention or extension to drop into it. Once this file has dropped into the directory and closes, the Receiver will match the file against the available Templates and instantiate the Task in the defined Queue within the System, where the appropriate processing will take place.

Typical Use: Automating jobs in a print environment


Adapter/XML

The XML Adapter is a file-based adapter and, similar to the File Receiver, monitors a directory for incoming files (usually extension .xml). Once the file is received the Adapter analyzes and matches the content against a template that is defined in the adapter and instantiates it into a queue where the task will be processed.

Typical Use: Automating jobs in a print environment


Adapter/MQ

The MQ Adapter is a message translator that waits for events to take place. Obviously, version control can be used to manage the adapter and template setup. Once a match is found the task template is instantiated in the queue, where it is processed.

One of the steps in the Task can be to respond to an incoming message and therefore allowing it to set up a bidirectional communication with other systems. An outside system can request a particular task that will send back what is defined within this task, or it will send back a document generated with the data provided from the incoming message.

Because MQ Series and ActiveMQ are software for cross-platform data transport, each end-node has an MQ Installation (regardless of platform) where a queue is defined. Software written by third parties can now send a message through an input queue and define the target queue where this message should be transported to. MQ doesn’t act on the message itself, but rather makes sure that the message is guaranteed to arrive at the destination.

Typical Use: Message delivery in online environments (correspondence, ad hoc printing or document request systems)

MQ Series Adapter for correspondence


Adapter/SOAP

The Adapter for Simple Object Access Protocol (SOAP) allows information exchange with defined message content structure to define data exchange with XML content via HTTP.

Typical Use: Message delivery in online environments (correspondence, ad hoc printing or document request systems) – similar to MQ

Related InformationFrameworks: SOA in Action

Papyrus SOA Adapter


Adapter/HTTPS - WebPortal

The HTTPS Adapter allows interfacing via the Hyper Text Transfer Protocol (HTTP) protocol, acting as the transport mechanism for Web-based requests from the Papyrus System. Just as the intent of a Web browser request is to return an HTML page from a WebServer, the HTTP Adapter/WebPortal works the same way. A customer’s application can send a message using the HTTP protocol to the HTTPS Adapter/WebPortal, which instantiates a task-based template and returns the result via HTTP (similar to the other adapters) or returns a PPL page to the requestor.

Typical Use: WebPortal applications, as well as third-party systems that use HTTP or HTTPS as the transport mechanism

Related Information - Technology Innovation Report: Webapplications


Adapter/SNMP

The SNMP Adapter responds to network monitoring requests (Simple Network Monitoring Protocol).

Typical Use: Third-party system monitoring of Papyrus System availability, for alarms or to trigger an event to resolve a potential problem.


Adapter/LDAP

The Lightweight Directory Access Protocol (LDAP) Adapter is used to receive and exchange user authorization from a third-party system by performing two tasks:
a) Import users from another system and b) verify with the external system whether the user is still authorized. With this Adapter, end-users do not have to keep a separate user ID and password when working in the Papyrus System and administrators only need to maintain a single environment.

Typical Use: Interface with third-party tools that manage users and their Roles, such as Active Directory or RACF


Adapter/POP3

The POP3 adapter is used to allow the system to instantiate jobs from templates when incoming e-mail is matched against a template. An additional step may automatically respond to the incoming message by generating and delivering a document.

Typical Use: Classifying Incoming emails and sending to respective user’s inbox, automatic generation and delivery of document; also triggering a formatting job on another node in the system


Adapter/SMTP

The SMTP Adapter is the outgoing counterpart to the POP3 adapter for email delivery.

Typical Use: Sending an outgoing e-mail with the content defined in a task; also sending notifications for jobs in an error state


Adapter/SMS

The SMS Adapter is used to send SMS messages via an SMS modem, but it is also capable of receiving SMS messages and triggering tasks. Currently, the adapter is enabled only to drive an SMS modem and not via TCP/IP yet. Due to the nature of SMS, it will send only short messages and not complete documents.

Typical Use: Notifications of task error or completion via SMS.


Adapter/XOM (SAP)

The XOM Adapter provides an interface for Papyrus to interact directly with SAP, allowing SAP to trigger a print task within the Papyrus System and receive feedback about the status of the job. The XOM itself is simply the transport mechanism, and the content - either ABAP output, RDI or XSF - of this XOM transfer is defined within the SAP system itself. Papyrus can interact with SAP without the Adapter, but the strictly unidirectional communication is file-based - Papyrus receives the data to be printed but no feedback is provided to the SAP system.

Typical Use: SAP customers want to control or see print job status from within the SAP GUI without changing to a separate system.


Adapter/Papyrus Host

The Papyrus Host Adapter is used to receive job information and data from the Papyrus Host system running on a mainframe. Running on the mainframe as a functional subsystem (FSS) to JES, the Papyrus Host component can detect from the parameters that a job is supposed to be executed by Papyrus and then send to the Adapter, where a task is instantiated and processed according to the template.

Typical Use: Processing jobs from the mainframe host that should be handled on the host but that are actually printed on the network.


Adapter/REST

The REST Adapter is an interface that allows communication with web services based on RESTful architecture.

The term REST Adapter stands for the REST interfaces provided by Papyrus Software:
  • Papyrus WebServer for RESTful Services (POC<xx>PPL, WebServer EYE-REST, PPL-REST, synchronous)
  • Papyrus WebServer in adapter mode (POC<xx>PPL, ADP.KNL, asynchronous)
  • Papyrus HTTP Adapter (POCxxHTP, asynchronous)

Any application (e.g. Java or JavaScript based application, the local common rule of a task inside Papyrus Objects) can make use of such web services via the REST Adapter using JSON for the data transfer (REST based on Papyrus WebServer for RESTful Services) or XML (REST based on Papyrus WebServer in adapter mode or HTTP Adapter).


Adapter/Enterprise Content Management Systems Interoperability (CMIS)

CMIS (Content Management Interoperability Services) is an open standard advanced by OASIS that facilitates interoperability between Enterprise Content Management (ECM) solutions of different vendors. Using CMIS, data can be exchanged between ECM systems using a vendor-neutral open specification and it also enables applications to access content from CMIS-compliant archival systems or document management systems.

ISIS Papyrus is committed to supporting the CMIS standard by providing the Papyrus CMIS Adapter on the Papyrus Platform. The Papyrus CMIS Adapter contains a server-side interface (Papyrus CMIS Service) and a client-side interface (Papyrus CMIS Client):

  • The Papyrus CMIS Service is a CMIS server and allows access from third-party applications to content stored in Papyrus Objects.
  • The Papyrus CMIS Client allows access from Papyrus Objects to third-party CMIS-compliant ECM solutions.

The Papyrus CMIS Adapter solutions implement the Web Services binding described in the CMIS specification and thus communicate using SOAP messages. The REST/Atom binding is additionally supported by the Papyrus CMIS Service (server-side interface).


Papyrus Type Manager

Papyrus Type Manager provides simple user and application access to query data from non-ISIS Papyrus databases, with native connection to SQL Server, Oracle and DB/2 and ODBC for other databases. Papyrus Type Manager eliminates the need to code database-specific SQL as well as to acquire or install a database client on each PC.