Integration of ERP and Print Management System

Masaryk University Faculty of Informatics

Integration of ERP and Print Management system

Master’s Thesis

Bc. Michaela Bocánová

Brno, Fall 2018

Masaryk University Faculty of Informatics

Integration of ERP and Print Management system

Master’s Thesis

Bc. Michaela Bocánová

Brno, Fall 2018

This is where a copy of the official signed thesis assignment and a copy ofthe Statement of an Author is located in the printed version of the document.

Declaration

Hereby I declare that this paper is my original authorial work, which I have worked out on my own. All sources, references, and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source.

Bc. Michaela Bocánová

Advisor: Mgr. Juraj Michálek

Acknowledgements

I would like to thank my supervisor Mgr. Juraj Michálek for giving me the opportunity to work on an interesting project that has future, and for providing me with SAP documentation.

iii Abstract

The thesis researches and develops solution for organisations running two different systems for submitting and processing a print job.The first part of the thesis cover theoretical background of Print Manage- ment Systems, specifically YSoft SafeQ. The second part covers theoretical background of Enterprise Resource Planning systems, specifically SAP and iDempiere. The last part documents implementation of the acquired knowledge. The result is successfull print job delivery from ERP to PMS.

iv Keywords

ERP, Enterprise Resource Planning, iDempiere, SAP, PMS, print, print management, Print Management System, IPP, Internet Printing Proto- col, SafeQ, Y Soft, YSoft

Contents

Introduction 1

1 Print Management 3 1.1 YSoft SafeQ ...... 4 1.1.1 Features ...... 4 1.2 Printing protocol ...... 5 1.2.1 SafeQ Protocol Level 4 ...... 5 1.2.2 IPP ...... 7

2 ERP 11 2.1 ERP comparison ...... 12 2.1.1 iDempiere v5.1, Compiere source code family . 12 2.1.2 SAP ...... 15 2.2 iDempiere ...... 17 2.2.1 Print ...... 18 2.2.2 Database access ...... 20 2.2.3 Ninja plugin ...... 20 2.3 SAP ...... 21 2.3.1 Print ...... 23 2.3.2 Command Line Interface ...... 27 2.3.3 Database access ...... 29

3 Connector 31 3.1 Requirements ...... 31 3.2 Implementation ...... 31 3.2.1 Environment ...... 32 3.2.2 Overall structure ...... 33 3.2.3 Core Package ...... 33 3.2.4 Printing Protocol Package ...... 35 3.2.5 ERP Package ...... 40 3.3 Installation ...... 47 3.3.1 iDempiere ...... 47 3.3.2 SAP ...... 47 3.4 Testing ...... 48 3.4.1 Exception handling ...... 48 3.4.2 Encountered problems ...... 48

vii Conclusion 53

Bibliography 55

Index 57

A An appendix 59

viii List of Tables

1.1 IPP message format 7 1.2 IPP attribute group format 8 1.3 IPP attribute field format 8 1.4 IPP additional value format 9 2.1 Ninja Column set 20 2.2 Submit status 28 2.3 Device status 29 2.4 Job status 30 A.1 Class Code (Table 1) 59 A.2 Callback Report Level (Table 2) 60 A.3 Area Code (Table 3) 60 A.4 Device State Code (Table 4) 60 A.5 Job State Code (Table 5) 61 A.6 Result Code (Table 6) 61

List of Figures

2.1 SPAD 24 3.1 Print from toolbar button in iDempiere 44 3.2 Print settings in iDempiere menu 45 3.3 Print settings in iDempiere window 45 3.4 Job delivery to YSoft Safeq 5 49 3.5 Job delivery to YSoft Safeq 6 50

Introduction

The goal of this thesis is to develop a tool that would connect Enterprise Resource Planning to Print Management Solution for the purpose of print job delivery. The main focus is on ERP system developed by SAP, and YSoft SafeQ Print Management System. Organizations, especially the larger ones, benefit from centralized management of their business processes and that includes processes related to printing. To support this feature, two types of systems are needed. One allows the organizations to manage day-to-day business processes, and share business related data across all the departments effectively and securely. Such system is called ERP and it stands for Enterprise Resource Planning. The other system allows the organizations to effectively manage a large amount of printers, and allthe print related processes. Such system is called PMS and it stands for Print Management System. The two systems work separately. Some organizations are satisfied with this solution. Some would prefer if their employees could request PMS’s print service directly from ERP’s UI. At minimum, the employee efficiency would be positively affected. The thesis researches APIs that provide developers with access to print jobs generated in the selected ERP systems, and printing protocols that are capable of delivering print jobs to YSoft SafeQ PMS. The researched ERP systems are iDempiere and SAP.They significantly differ in their printing capabilities. The first chapter starts with brief introduction to print management and follows with a summary of YSoft SafeQ’s features, and techni- cal information on printing protocols, specifically Internet Printing Protocol and YSoft SafeQ Protocol Level 4. The second chapter provides brief characterization of ERP systems and follows with detailed description of print integration in system iDempiere and SAP. The third chapter describes implementation of print job delivery in both ERP systems. The chapter includes analysis of requirements, brief information on installation and results of testing. Because the thesis is realized with Y Soft corporation, a.s., the job delivery is tested with YSoft SafeQ.

1 Print Management

Print management is implemented in Print Management Software (PMS). PMS is complex software designed for effective management, mon- itoring, and optimization of a collection of print devices, and all the processes related to printing. The management is centralized and the print devices can be either local or remote. The software incorporates drivers and programs that make the printer devices compatible with other devices such as computers, smartphones and special external terminals. The general workflow is:

1. a print client generates a print job

2. the client prints the job through a software interface

3. a print driver renders the job for printing

4. a print server receives the job and forwards it to a print device

5. the print device prints the job

The print client is a device or software that can initiate communication with the print server and send a request for print. The client can be a laptop, a smartphone or any other device connected to the print server within the same network. The software interface is an interface installed on the print server. The print driver is software that translates print jobs sent by the client into language a specific print device understands. The print server is a device or software that is connected to a collection of print devices over a network. As a result, all clients can have access to this collection. After the server receives one or more print jobs from one or more clients, it sends them to a specific print device. The print devices range from small desktop printers, scanners, copiers and faxes to large MFDs. The acronym MFD stands for Multi-Function Device. MFD incorporates the functionality of multiple devices in one, and is used mainly in office environment.

3 1. Print Management

PMS is capable of managing and controlling the print queues, the volume of printed documents, the print formats, the user accounts and the billing accounts, the network printer devices and so much more. An integral part of PMS is user authentication for accessing print services and printer devices. The main benefits of using PMS are reduced cost by eliminating wasteful printing and increased security by managing access to print services. The next section describes features of PMS developed by Czech company Y Soft.

1.1 YSoft SafeQ

Y Soft is a software company with headquarters located in Brno, Czech Republic. It was founded in 2000 by Václav Muchna, the CEO, and Martin de Martini, the CIO. The company offers solutions suitable for large institutions, such as banks, insurance companies, hospitals, universities and schools, and offices. The main product the company offers is YSoft SafeQ. The newest version is YSoft SafeQ 6. YSoft SafeQ is designed as a software platform that supports not only print management but document capture and 3D print management too. It can be deployed on-premise, or as a private or hybrid cloud.

1.1.1 Features YSoft SafeQ offers a large variety of features and modules. The key feature is secure printing. Secure printing is enforced by the usage of the combination of print authentication and secure queue. When a print job is sent to secure queue, the spooler holds the job until the owner authorizes the print. Only the owner can print the job. YSoft SafeQ offers numerous methods for user authentication, including username and password, or ID cards. A feature that significantly decreases time consumption is print roaming combined with universal print driver. Print roaming supports printing on any printer managed by YSoft SafeQ system within the organization. The feature is enabled by the use of YSoft Universal

4 1. Print Management

Print Driver. This means that the job can "follow" its owner to any such printer regardless of their physical location or vendor. A feature that further reduces time consumption is mobile print. Mobile print supports secure printing from laptops, smartphones or tablets, including secure guest printing. A cost reducing feature is credit and billing. Credit and billing in combination with YSoft Payment Machine enable users to track cost of each submitted print job and make an informed decision about the job. Among the rest of the features are automated workflows for repet- itive print tasks, extensive reporting support and user management combined with governance rules.

1.2 Printing protocol

“Network Protocol is a set of rules that defines the format and the order of messages exchanged among two or more communicating entities, as well as the actions performed during sending or receiving that messages.”[1, p. 13] Printing protocol is a special network protocol that describes communication over network between a device that is used to send a print job and a printer or a print server that is used to receive and print the job. JetDirect port with number 9100 allows for direct job delivery. That means a user is able to send raw print job data directly to the printer listening on port 9100. Two printing protocols were selected for implementation and they are described in the folowing sections.

1.2.1 SafeQ Protocol Level 4 SafeQ Protocol is a client-server side protocol. It must follow certain rules: ∙ The server side is represented by YSoft SafeQ print server. ∙ The server needs to open the JetDirect port. ∙ The protocol is message oriented.

5 1. Print Management

∙ Client opens connection to server.

∙ Client sends request and server returns response.

∙ Client can send multiple requests.

∙ If server does not receive a request from client in defined timeout, the connection to client is terminated.

Several rules apply for format of messages in request header too:

∙ Each request must contain the defined common prefix.

∙ Every command must be terminated by a newline character.

∙ Data must be sent in blocks with predefined length.

∙ All requests must be encoded in UTF-8.

∙ Users are required to authenticate themselves.

Prior to sending data:

∙ client must initiate communication with defined request.

∙ client must send information about protocol level.

Some of the optional requests are:

∙ client may send information about job, such as number of copies, paper size, duplex, and black and white.

∙ client may request compressed communication.

∙ client may request encryption.

∙ client may request information about job status or job size.

∙ client may request for disconnect.

∙ client may set document title.

6 1. Print Management Table 1.1: IPP message format

Field Size Required version-number 2 bytes yes operation-id or status-code 2 bytes yes request-id 4 bytes yes attribute-group n bytes (0 or more) no end-of-attributes-tag 1 byte yes data q bytes no

Three options for user authentication are supported: The first option is through the protocol. The second option is to wrap print data in PCL and add a PJL header with username. YSoft SafeQ parser uses a regular expression to parse the username from the PJL header. The regular expression can be configured. The third option is to add username to job title. YSoft SafeQ parser parses the username using delimiters. The delimiters can be configured. It is possible to send job from command line using netcat tool.

1.2.2 IPP IPP is an acronym for Internet Printing Protocol, and it is a standard client-server side protocol. It uses HTTP for communication on a TCP port 631[2, p. 19]. The content-type property of HTTP connection needs to be set to application/ipp. The protocol also provides encryption using TLS layer. For every request server receives, a response is sent. IPP 1.0 was released in 1999, IPP 1.1 in 2000. The Printer Working Group released IPP 2.0. The newest standard is IPP Everywhere and it was released in 2013. IPP request or response message format is described in table 1.1. ∙ The version-number represents a version of IPP that is supported by printer. It consists of major number and minor number. ∙ The operation-id identifies operation a client requests. print-job, print-uri, create-job, get-jobs. ∙ The status-code is always sent in response.

7 1. Print Management Table 1.2: IPP attribute group format

Field Size begin-attribute-group-tag 1 byte attribute p bytes (0 or more) attribute-with-one-value q bytes additional-value r bytes (0 or more)

Table 1.3: IPP attribute field format

Field Size value-tag 1 byte name-length 2 bytes (value is u) name u bytes value-length 2 bytes (value is v) value v bytes

∙ The request-id identifies request.

∙ The attribute-group represents an array of attributes and the group is identified by a special value. End of group is identified by end-of-attributes-tag. Four types of groups are defined:

– operation attributes, e.g. attributes-natural-language, attributes- charset or job-name, – job attributes, e.g. copies or sides, – printer attributes – and unsupported attributes.

∙ data is print data sent by client

Each "attribute-group" field is encoded by the table 1.2. Each "attribute-with-one-value" field is encoded by the table 1.3. Each "additional-value" field is encoded by the table 1.4.

8 1. Print Management

Table 1.4: IPP additional value format

Field Size value-tag 1 byte name-length 2 bytes (value is 0x0000) value-length 2 bytes (value is w) value w bytes

2 ERP

ERP is an acronym for Enterprise Resource Planning. It refers to a suite of applications or modules used by companies of all sizes to manage vital, day-to-day business processes, such as manufacturing, accounting, project management, human resources, customer relationship management and shipping. A key principle of ERP systems is the central data management. As opposed to decentralized management, centralized management enables effective exchange of data between the processes, without duplicities or loss of integrity. All ERP users, regardless of the department they are a member of, access one centralized data repository to ensure the data is correct, up to date and secure. The core functionalities of ERP systems can be distributed among three modules: ∙ Customer Relationship Management (CRM)

∙ Supply Chain Management (SCM)

∙ Material requirements planning (MRP) The vendor-specific ERP systems provide the core functionalities and more. Further information on the topic of ERP systems, specifically their history, types and benefits, is available in bachelor’s thesis: https: //is.muni.cz/th/qz9d4/Vyvoj_plug-inu_v_ERP_systeme.pdf. Many companies use ERP systems that provide them with connection to multiple locations and suppliers around the world. Usually, the user of ERP system can print to the printer they are directly connected to using OS middleware or possibly a web browser plugin. But user may need to print specific reports, invoices or other documents to other printers at any location that is inside the corporate network or outside the corporate network, for instance to another office, supplier or customer. In order to enable secure remote printing from ERP system to any printer at any location, a print management system and a connector to this print management system is needed. Prototype of the connector that provides integration between ERP and print management system was developed as a part of the thesis.

11 2. ERP 2.1 ERP comparison

The section contains brief summaries of two ERP systems. The researched properties were business model, used technologies, hardware requirements, supported platforms, client technologies, community, customization options, architecture, reporting options, print integration, security, localization, deployment and migration options.

2.1.1 iDempiere v5.1, Compiere source code family Business model:

∙ open source

Technologies:

∙ programming languages:

– Java 8, – SQL, – XML, – HTML, – JavaScript, – CSS

∙ platform:

– OSGi framework for plugins, – web server Jetty 9.4.7, – ZK 8.0.2.2 web GUI framework

∙ DB backend:

– PostgreSQL >= 9.1, – Oracle >= 11G

HW requirements:

∙ server >= 340 MB HDD

12 2. ERP

∙ for 1 user >= 900 MB RAM, 1 CPU core

Supported platforms:

∙ OS:

– Windows, – Linux, – Mac

∙ browsers:

– Firefox, – Chrome, – Opera

∙ Cloud support – no

Client technologies:

∙ desktop - deprecated

∙ web - simple eshop included

∙ mobile - responsive UI

Community:

∙ end users, Subject Matter Specialists, Implementers

∙ main developers: Carlos Antonio Ruiz Gómez, Le Quy Hiep, Heng Sin Low, Redhuan D. Oon (community leader)

∙ google groups forum - best option, IRC - chatroom and regular meetings

∙ IDE: Eclipse Oxygen + Buckminster, Equinox (OSGi), Apache Felix Web Console

∙ JIRA issue tracking system ∙ https://plus.google.com/communities/107237178393636704520

13 2. ERP ∙ https://twitter.com/idempiere

∙ https://www.facebook.com/groups/idempiere/about/

∙ youtube manuals - redhuan d. oon, evenos Consulting GmbH

∙ red1 blog

Customization:

∙ Application Dictionary (no coding needed): entities, tables, columns, menu, views, layout, translations...

∙ application of changes (flush cache required or role access update)

∙ Ninja plugin

Architecture:

∙ OSGi

Reporting:

∙ PDF, HTML, XLS formats

∙ Jasper Reports integration

Print integration:

∙ print formats

∙ system printers, via Acrobat PDF plugin too

Security:

∙ password storage – stored in plain text, user must run a specific process to convert passwords to one way hash and salt (SHA-512)

∙ encrypted communication (sun.security.ssl)

∙ role based access

Localization:

14 2. ERP

∙ default: english, spanish

∙ decent czech support

Deployment:

∙ Console based installation scripts

∙ test site at https://test.idempiere.org/

∙ source at https://bitbucket.org/idempiere/idempiere

∙ API documentation at https://www.globalqss.com/idempiere/ 5.1_20171111/javadoc/

∙ wiki websites (chaotic) at http://wiki.idempiere.org/en/Main_ Page

∙ download at https://sourceforge.net/projects/idempiere/

Migration:

∙ loading/migrating data to/from DB (2Pack – XML files, CSV files)

∙ upgrade scripts for DB and server

2.1.2 SAP Business model:

∙ German company SAP SE

∙ commercial

Technologies:

∙ C, C++, ABAP, Java, Python

∙ databases: SAP HANA (in-memory), Microsoft SQL, Oracle, IBM DB2, MAXDB, SAP ASE + tools

HW requirements (SAP HANA 2.0 VM):

15 2. ERP

∙ Intel-based hardware platforms

∙ IBM Power Systems

∙ for SAP HANA Express VM: >= JRE 8, >= 8 GB RAM, 120 GB HDD, >= 2 cores

Supported platforms:

∙ OS Windows, Linux, Mac 64

∙ Web Browsers: Safari, Firefox, Chrome, Microsoft

∙ SAP Cloud platform, Amazon, Google, Microsoft, IBM, Alibaba

Client technologies:

∙ web client

∙ desktop: SAP Business Client

∙ mobile: SAP Business One

∙ smartwatch for S/4Hana

Community:

∙ users, developers, and partners

∙ SAP HANA International Focus Group, podcast, youtube, blog

Customization:

∙ tables, rows configuration

∙ layout configuration

Architecture:

∙ system architecture: x86_64, PowerPC

∙ extensions – download manager

∙ external processes - call via API

16 2. ERP

Print integration: ∙ OS spooler ∙ server spooler (own spool service and spool database) ∙ bi-directional communication - job state ∙ BC-XOM - high-availability no ∙ LPR - high-availability yes Security: ∙ encrypted communication: Secure Network Communications Deployment: ∙ Console based installation, manual Migration: ∙ SAP Migration tools Localization: ∙ Czech and Slovak as well

2.2 iDempiere

IDempiere, also known as OSGi + Adempiere, is an open-source ERP suite. The suite is driven by a strong community and is distributed under the GNU that stands for General Public License. The primary source of support is the iDempiere Google group. The system is more suitable for small to medium businesses. It does not support as many functions as commercial systems such as SAP, but it provides all the core functionalities of ERP systems. IDempiere is highly configurable and customizable, which allows users to modify and adapt the ERP system to the company’s processes without the need of changing or rebuilding the source code. Moreover, it uses OSGi framework which allows developers to customize and extend the system in the form of OSGi plugins. More information, including history, software and database architecture, is in my bachelor’s thesis: https://is.muni.cz/th/qz9d4/ Vyvoj_plug-inu_v_ERP_systeme.pdf

17 2. ERP

2.2.1 Print This section introduces printing possibilities in iDempiere (and ADem- piere and Compiere too). Described below are:

∙ user views:

– print format table, – print format form, – jasper;

∙ user access:

– report button, – print button, – menu;

∙ data types:

– window data, – financial data. iDempiere webui User can create reports containing generic data that exist inside one of the many iDempiere windows or financial data. Every report has a print format assigned. IDempiere supports multiple clients. One client controls the configuration of the system and another client serves all the business needs of the company. Some print formats belong to system client administration role, some belong to company client administration role. A number of print formats can be found in the menu. The formats have two different layouts: columnar list for table based format and form for form based format. After clicking the report button, a print format table shows up and user can customize the generated report on the fly, that is without the need to recompile the code. User can create a new table based print format and set headers, lines, columns, etc. Afterwards user can

18 2. ERP

export the generated report to PDF, XLS or HTML. The generated report consists of a raw table. Print format form view is accessible from the print button and from the menu. Just like before, user can customize the report on the fly and export it to PDF, XLS or HTML. Although, the generated report is not just a raw table anymore. In addition to capabilities of the table based print format, the form based print format allows user to include boxes, background shading, embed table based format, etc. IDempiere has integration with Jasper. Jasper offers significantly larger amount of control as opposed to the previous two options. The downside is inability to create Jasper reports on the fly. It is necessary to compile the report and release it with code. Another disadvantage is that to create more advanced Jasper reports, Jaspersoft studio is needed. The generated reports are temporarily saved to disk. To summarize, user has two simple to use but primitive options of report formatting and one option that is more complicated and harder to learn but much more advanced.

API iDempiere offers these custom, document related engines:

∙ DataEngine that creates an XML document.

∙ LayoutEngine that customizes a layout of a report.

∙ ReportEngine that references DocumentEngine and LayoutEngine and generates a report with specific layout and output format, namely PDF, XLS or HTML.

∙ ArchiveEngine that references ReportEngine and archives reports.

The capabilities of these engines were used in the development stage.

Print integration IDempiere supports only two methods of printing. One is from OS via ADempiere client. The other is via internet browser.

19 2. ERP Table 2.1: Ninja Column set

Prefix Meaning Size Q# Quantity 11 Y# Yes/No 1 A# Amount 11 D# DateTime 11 T# Text 2000 L# Items separated by "/", e.g. L#Weekdays

2.2.2 Database access

IDempiere supports only two vendors of database systems: PostgreSQL and Oracle. PostgreSQL is free and open-source. Oracle is proprietary. The database access is set up during the installation of the ERP and the data is imported manually through the script provided by the installation.

2.2.3 Ninja plugin

Ninja plugin was developed by Redhuan D. Oon. The plugin makes customization process far more effective. Below is description of ninja’s capabilities relevant to the development stage. Ninja module creator enables developers to design custom ERP module on the fly. A module contains a collection of designed models with sequence numbering. The purpose of sequence numbering is to ensure correct order of models according to dependencies on other models. Developer can design models, such as new menu, info window, window with tabs and fields, table with columns, workflow guide, via ModelMaker CodeMaker allows developer to set location of blank plugin where generated ORM of all models are populated. Process GenerateModel first generates model data and than ORM in blank plugin. Afterwards, further manual coding can be done. To create a new model, the field ColumnSet must be filled. Itcan contain values described in the table 2.1. The values are separated by comma.

20 2. ERP

CodeMaker can populate the blank plugin downloaded from http: //bitbucket.org/red1/org.red1.blank. More information about the older version of Ninja plugin can be found here: http://red1.org/adempiere/viewtopic.php?f=45& t=1821#p8742. More information about the Ninja Plugin can be found here: http: //red1.org/adempiere/viewtopic.php?f=45&t=1831.

2.3 SAP

SAP is one of the largest vendors of ERP software. SAP stands for Systems, Applications and Products. SAP was founded in 1972 by five former employees of IBM in Germany. SAP R/1 was released in 1973. It had a single-tier architecture in which presentation, applications and data were on one platform. SAP R/2 was a mainframe version released in 1979. It had a two-tier architecture, where presentation was on one platform and applications and data were on another. SAP R/3 was released in 1992. It was a client-server model, and had a three-tier architecture, in which presentation, applications and data were housed separately. The R stands for "Real-Time" data processing and the number identifies the type of architecture. MySAP launched in 1999 and in 2004 the company launched SAP NetWeaver, and the successor to R/3, SAP ERP system (or SAP ECC, short for SAP ERP Central Component). SAP S/4HANA was released in 2015 and offers deployment on- premises, or as a cloud or a hybrid. S/4HANA is a real-time database developed by SAP. The three-tier architecture is a type of architecture where

∙ database layer handles data retrieval, storage and management,

∙ application layer implements business logic,

∙ and presentation layer provides user interface.

Each layer components are deployed on different type of server.

21 2. ERP

∙ Database servers contain specialized systems with fast and large hard-drives. An example is Oracle, Microsoft SQL Server, IBM DB/2, Siebel and Sybase.

∙ Application servers include specialized systems with multiple CPUs and a vast amount of RAM. Application Layer serves as a purpose of a communicator between Presentation and Database Layer.

∙ Presentation servers contain systems capable of providing a graphical interface. Presentation Layer is a GUI that stands for Graphical User Interface. An example is Desktop, laptops or smartphones.

SAP solutions include a number of functional modules which support key business processes, such as:

∙ Financial Accounting (FI) which tracks finances across the organisation.

∙ Controlling (CO) which controls, monitors, and optimizes all the business processes in an organisation.

∙ Materials Management (MM) which deals with movement of materials via other modules like logistics, supply chain management, sales and delivery, warehouse management, production and planning.

∙ Sales and Distribution (SD) which monitors processes such as products enquires, quotation, placing order, pricing, scheduling deliveries, picking, packing, goods issue, shipment of products to customers, delivery of products and billings. These processes involve modules such as FI (Finance Accounting), CO (Control- ling), MM (Material Management), PP (Production Planning), LE (Logistics Execution).

∙ Logistics Execution (LE) which deals with shipment of goods and warehouse management. These two modules are integrated with sale and distribution, material management, and production and planning.

22 2. ERP

∙ Supplier Relationship Management (SRM) which ensures effective and efficient transition of products and services between an organization and its suppliers. This module can effectively integrate with planning, accounting, and inventory system.

∙ Customer Relationship Management (CRM) which deals with end-to-end customer related processes. CRM is designed to cen- tralize the data related to all the customers associated with an organization.

∙ Human Resources (HR) which collect employee-related data for administrative, time-recording, and payroll purposes.

∙ Advanced Business Application Programming (ABAP) which is a programming language that runs in the SAP ABAP runtime environment, created and used by SAP for the development of application programs. All of R/3’s applications were developed in ABAP. ABAP is an event-driven programming language. User actions and system events control the execution of an application. ABAP is also called ABAP/4. The “4” in ABAP/4 stands for “Fourth Generation Language” or 4GL.

∙ SAP HANA where Hana stands for High-performance Analytic Appliance. SAP HANA is an in-memory computing platform that allows real-time data analysis.

SAP provides various kinds of supports and services through its portal at: https://support.sap.com/en/index.html. Some of the supports are SAP Notes, SAP Knowledge Base Articles and SAP Com- munity content.

2.3.1 Print The print process in SAP can be explained in three simple steps. First, a user generates a spool request, which is stored in TemSe. TemSe is a special storage system that can store data produced by the system or the user either in the SAP database or in the file system of the operating system. The data is stored in OTF format. Second, the user creates one or more output requests for the spool request. Third, the

23 2. ERP

Figure 2.1: SPAD user or the system receives a reply of either successful or unsuccessful printing. Unlike iDempiere, SAP has developed a complex spool system. The configuration of the system is possible through Spool Admin- istration. SAP also offers a BC-XOM interface, which provides a generic interface to SAP NetWeaver spool system, enabling communication between SAP NetWeaver spool system and an external output management system. The following sections describe the BC-XOM interface. The current spool administration is divided into four areas:

1. Devices/servers

2. Output management systems

3. Device types

4. Character sets

Devices/servers The spool system supports delivering data from within the system to external output devices. A user needs to specify the destination output device in advance to generating output requests from the system. The destination output device is associated with a real, physical device and the system needs all necessary information about the device to

24 2. ERP

address it correctly. This information includes device type, access method, formatting of output, etc. Spool work process is a work process in an SAP instance which provides formatting and outputting of output requests. Each output device in the spool system is assigned to exactly one instance with a spool work process and the work process is assigned to an unlimited number of output devices. The spool work process is running on a particular spool server. The system supports real and logical spool servers which allow for grouping output devices. Output device contains information on how to access or address an associated physical device. This information includes an access method which provides information required for creating a connection between the spool system and physical device (printer) and how the output system communicates with the device. The SAP system, specifically the spool work process, needs this information tosuc- cessfully transfer data to host spool system for this device. The spool system supports twelve access methods. They allow printing locally, remotely, locally using LP/LPR, archiving, mailing, etc. For instance, access method E describes printing using an external output management system, meaning the device is connected through an external output management system (OMS). Destination host is the host computer which receives the trans- ferred output data.

Output management systems

An important part of the spool work process is the output management system. The output management system supports establishing a connection to the target output device according to the access method, transferring of the output request to target output device, querying of output requests filtered by device and querying of the print queueof the output device. The output management system is divided into two categories:

1. ROMS, short for Real Output Management System

2. LOMS, short for Logical Output Management System

25 2. ERP

A real output management system describes attributes of OMS including a way to query job and device status, a way to execute OMS commands, etc. A logical output management systems can be assigned to one real output management system. The LOMS definition contains a subset of attributes of the ROMS. Each output device which is accessed using access method E can be assigned a LOMS. LOMSs allow the user to operate output devices of a ROMS in various ways. For instance, the user can use printing from command line, meaning only the ROMS are used that provide Command line interface, and specific OMS commands for a specific operating system of the application server can be defined in LOMS.

Device types

The spool system supports formatting of output data by converting the raw data from the system into a printer language which the destination device understands, e.g., PCL, PostScript. The formatting is associated with a type of printer (device type), meaning one format can be shared by multiple printers of the specified device type. The system also supports importing of third-party device types (e.g. Hewlett-Packard company: https://support.hp.com/hk-en/document/c05051702 ). New (custom) device types contain prefix Y or Z in the name. Print controls of device type are formatting commands which are embedded into the output data as a string. They can be used to change a character font, font size, font style (bold, italics), etc. The SAP system provides a way to define a set of formats for a device type, e.g., format type X_65_80 is for ABAP lists with at least 65 rows by 80 columns. These formats consist of actions which can be triggered at printer initialization, page start, page end, line start, line end, etc. They contain data which are embedded into output data. A page format describes paper size and orientation (landscape or portrait).

26 2. ERP

Character sets Character set is a character set that printer understands. The output data is converted from the system character set to this character set during formatting.

2.3.2 Command Line Interface Command Line Interface is defined by a set of command templates which are stored in the database (in table TSPCMDS). There is no need to restart the system to modify these command templates. The supported logical commands of LOMS are: ∙ SUBMIT (job submit transfers a job from spool work process to the OMS) ∙ DPOLL (device polling queries submitted jobs at an output device) ∙ DQUERY (device queue query queries the entire queue) ∙ CANCEL (job cancel cancels/deletes a job upon user’s request) ∙ JQUERY (job status query returns information on job status) ∙ PATH (path placed in front of the command) The command set is used by specific LOMS and operating system. Command format is a format of a command line command with arguments passed by the system. Arguments are parsed by the shell. Special characters are escaped differently depending on operating system. After submitting a OMS command, a reply is expected in the form of lines of text in the standard output data stream. Each line contains several data fields which are separated by white spaces. The first data field is obligatory and contains a version of the reply format. The version of the formats described below is 2.00. The last data fields may contain a human-read message. The first field of the message contains the default message and the additional fields may contain its translation into different languages. Unknown values of the data fields are represented by a dash (-). Spaces are escaped by a backward slash (\). Single slash is represented by double slash (\\).

27 2. ERP Table 2.2: Submit status

Field Meaning Required Version format x.xx (major.minor number) yes Class code Table 1 yes Area code Table 3 yes OMS spool ID Unique ID generated by the OMS yes Message Optional message from the OMS no

Job Submission The command submit can accept a large number of arguments. The required arguments are: SAP spool ID (&EI) which is required by the spool system during the device polling, ID of an RMG (&EG) which is required during polling to specify the information to be returned, destination (&P) which represents device of the OMS and document (&F) which contains a full name of the file that contains the print data. Some of the optional arguments are: SAP user (&O) which contains name of the owner in SAP, SAP user (&o) which contains name of the user, who created the output request, SAP user (&R) which contains name of the receiver of the output, SAP title (&T), number of copies (&C), name of real OMS (&Er), name of logical OMS (&El), short name of the SAP printer (&S), number of SAP spool request (&N), and number of output request for spool request (&n) The submit command template in LOMS can looks like this: submit.sh –spool-id &EI –file "&F" –title "&T" –owner "&O" –receiver "&R" –rmg &EG –destination & –LOMS "&El" And the substituted command can looks like this: submit –spool-id 000000042800001 –file /usr/sap/NPL/D00/data/0000wqSv.NPL –title test –owner SAP* –receiver SAP* –rmg PNPL_00rihy –destination rihy –LOMS SQCMD

The submit command must output a message in the format described in table 2.2. In case of success, the line outputted to console could look like this: "2.00 4 2 - submit\succeeded"

28 2. ERP Table 2.3: Device status

Field Meaning Required Version Format x.xx (major.minor number) yes Device state code Table 4 yes Class code Table 1 yes Area code Table 3 no Message Detailed information, logged by R/3 no

In case of failure, the outputted line could looks like this: "2.00 1 5 - exception\occured”

Device Polling The command can accept only three arguments. The required argument destination (&P) which represents the logical device of the OMS and either reply message group (&EG) or list of job IDs separated by spaces (&EL). The command template can look like this: poll.sh &P &EG The substituted command can look like this: poll rihy PNPL_00rihy

The command must first output device status in the format described in table 2.3. Next the command can output several job statuses in the format described in table 2.4. The output could look like this: 2.00 XX.X000012 4 1 poll\ok 000000042800001 2 4

2.3.3 Database access Databases are configurable via transaction DBCO (table DBCON). The DBA Cockpit is a platform-independent tool which can be used to monitor, configure and administer SAP’s databases. After installation

29 2. ERP Table 2.4: Job status

Field Meaning Required SAP spool ID Internal spool ID of calling R/3 yes Job state code Table 5 yes Class code Table 1 yes Area code Table 3 no Result code Table 6 no Queue position Position in queue no Message Detailed information, logged by R/3 no of the system, the DBA Cockpit needs to be explicitly configured. Oth- erwise the cockpit will not work and will show errors. SAP distinguishes between its primary database and multiple sec- ondary databases. This feature can be used for outsourcing complex database queries. Supported vendors are: Sybase, SAP Hana, IBM DB2, MSSQOL and Oracle.

30 3 Connector

The goal of this master’s thesis is to design and implement a tool which will allow companies running one of the selected ERP systems to successfully deliver a print job to YSoft SafeQ spooler system.

3.1 Requirements

The requirements for the connector are described below. In order to use the connector as an efficient and preferable connection and communication tool with YSoft SafeQ, the tool needs to be easy to use and easy to install. The connector needs to successfully deliver a print job, provided the correct connection settings are applied. The connection settings need to be configurable. The connector should support at least one printing protocol with possibility to add more printing protocols implementations in future. It should support at least one ERP system. A common feature of ERP systems is document generating. While the process may differ, the generated document is usually saved in a temporary location on disk. The connector needs access to this location in order to send the generated document to the spooler. The connector should support synchronisation of job statuses in YSoft SafeQ spooler with job statuses in ERP system as well as synchronisation of device statuses. As a result, ERP users will be able to monitor current statuses of their print jobs or devices directly from ERP UI without switching to another system. Support of scanning feature is expected too.

3.2 Implementation

The solution supports all requirements beside job status and device status synchronisation, and scanning. The synchronisation and the scanning feature are a subject of future research and development and therefore this thesis does not include any more detail on them. Below is the description of the solution As there was no necessity to implement the connector as a standalone service, the connector is realized as a stateless command line tool

31 3. Connector for ease of implementation and use. In order to support a variety of different ERP systems with different architectures and capabilities, it was preferable to implement the connector with future use of its core functionality in the form of a library for all potential ERP implementations in mind. Therefore, the connector runs from within ERP UI. As a result, no re-training for ERP users is required. The connector was implemented for two ERP systems: first iDempiere and subsequently SAP. The connector supports two protocols: SafeQ protocol level 4 and IPP. However, the protocols are not implemented fully. Their purpose is purely demonstrational. The connector is configurable via a simple text file and a shell script in case of SAP, and a database table incase of iDempiere. The connector needs to switch between ERP systems implementations, printing protocols implementations and databases implementations. Therefore a bridge design pattern was applied. In order to register supported protocols, databases and other functionalities, a builder design pattern was applied. The connector offers a command line interface. Used was a third-party implementation, jCommander developed by Cédric Beust. The connector sends print job encoded in UTF-8 as SafeQ 6 supports UTF-8 only. Further implementation detail is divided into these sections: Envi- ronment which describes used technologies, Overall structure which describes the implementation at its highest level, And individual packages.

3.2.1 Environment These technologies were used in the development stage:

∙ As a programming language, Java was selected for its platform independency. The used version of JDK was 1.8.0_181.

∙ The third-party libraries were downloaded from Maven repository. The used version of Maven was 3.5.4.

∙ All UML diagrams throughout the thesis were created via Visual Paradigm 15.2.

∙ As IDE, Eclipse Photon JEE was selected in order to successfully build iDempiere.

32 3. Connector

∙ The development and testing was carried out on Windows 10.

∙ iDempiere was installed on Windows 10. Two versions were tested: 4.1 and 5.1.

∙ For automated model classes generation, Ninja plugin, developed by Red , was installed on iDempiere.

∙ SAP 7.51 SP02 (not SAP 7.50 SP02) was installed on openSUSE version 42.1 (not Thumbleweed).

3.2.2 Overall structure At the highest level, the connector contains:

∙ a source directory with the source files and development infras- tructure,

∙ and a resource directory with the configuration file and shell scripts.

The functionality of the connector is implemented in the package ys.connector. This package is further divided into three packages according to the general purpose of each individual functionality aspect:

∙ Core,

∙ ERP,

∙ and Protocol.

3.2.3 Core Package The core package is shared by ERP implementations, printing protocol implementations, and store implementations. The package implements a main Connector class that is respon- sible for initializing the connector with the help of the class Builder. The class Builder is an implementation of the builder design pattern and it builds the connector by registering all the supported printing protocols, stores, and commands. The supported protocols, stores,

33 3. Connector and commands are registered under a unique alias, and managed by their relevant manager classes, ProtocolsManager, StoresManager, and CommandsManager. The CommandManager store pairs of Com- mands and their relevant parameters. The class ConnectorProperties maintains central collection of the names of the connector properties, also called parameters. The parameters are configured in the (.+)Parameters classes. The class also loads properties from the configuration file into a java.util.Properties instance. The loaded properties are than compared to the assigned command line arguments and the default values in the class Connector- Provider. The ConnectorProvider implements a third-party interface IDefaultProvider from the third-party parser jCommander. Once the connector is built, it is prepared to parse the arguments delivered by the SAP system, the scripts, and the configuration file. The configuration file is specified in the system property in the scripts. The connector supports two methods of parameter assignment:

1. ConnectorProvider which is a class that assigns default values to the parameters. It makes decisions between the values inside the configuration file and the default values in the Connector- Provider class. Nonempty value is preferred.

2. SAP’s Command line values which are the values submitted by the SAP system and/or the user. They are captured in the relevant script. The Command line values overwrite the previous, default values.

The Connector can configure logging to file too. The API usedis java.util.logging and the class is called ConnectorLogger. Connector- Logger accepts parameters such as log file path, log to console, and log file size. This package contains several parameters classes. One is called MainParameters and it consists of parameters such as: Help which determines whether the usage is to be printed or not, LogDir which contains an absolute or relative path to directory where logs are to be stored, LogToConsole which determines whether the log messages should be printed to the console too, Loglevel which limits the log messages according to their java.util.logging.Level. The last three parameters are referenced in the class ConnectorLogger.

34 3. Connector

To assign parameters of data types other than java.lang.String, this package implements numerous converter classes such as: Charset- Converter which can convert the string to java.nio.charset.Charset, LogLevelConverter which can convert the string to java.util.logging.Level, ProtocolConverter which can convert the string to printing protocol class, StoreConverter which can convert the string to store class. These classes implements third-party interface com.beust.jcommander.IStringConverter<>. At last, the built connector can run the parsed command by invok- ing the run method in the class CommandAction.

3.2.4 Printing Protocol Package The connector partially supports two printing protocols, SafeQ Proto- col Level 4 and IPP 1.1. With help of factory and bridge design pattern, the user or the system can easily switch between the two. Both SafeQ protocol and IPP protocol use sockets to communicate with YSoft SafeQ spooler system. The SafeQ Protocol is implemented in class SQJetDirect, and IPP is implemented in class Ipp. The next section explains the communication between sockets in general.

Java sockets Network communication between applications programs means delivering data from one port to another using a transport protocol. Two types of communication are possible: connection-oriented and connectionless. Connection-oriented transport protocol is TCP and connectionless transport protocol is UDP. The connector uses TCP protocol. The TCP protocol establishes a communication link between a source IP address and port and a destination IP address and port. The connection between the ports is alive until the communication link is terminated. TCP implements error-detection and error-correction mechanisms that ensure reliability of the connection. The connection is implemented as a stream of bytes from source to destination. Pack- age java.io provides numerous stream I/O classes. The connector uses BufferedInputStream and BufferedOutputStream. As opposed toTCP, the UDP protocol does not establish a link for the duration of the connection. When application program uses UDP for communication

35 3. Connector with the destination, it first writes the destination IP address and port on a datagram and then sends the datagram to its destination. UDP does not implement any error-detection or error-correction mechanisms therefore it is less reliable than TCP. YSoft SafeQ requires TCP connection. The connector is a client socket and YSoft SafeQ is a server socket. The socket based client-server communication is supported by several classes in the java.net package. The InetAddress class encapsulates In- ternet IP addresses and supports conversion between dotted decimal addresses and host names. The Socket, ServerSocket, DatagramSocket, and MulticastSocket classes implement client and server sockets for both types of communication. The DatagramPacket class is used to con- struct UDP datagram packets. The SocketImpl, DatagramSocketImpl and the SocketImplFactory interface provide environment for implementing custom sockets. The URL, URLConnection, HttpURLConnec- tion, and URLEncoder classes implement high-level web browser- server connections. The ContentHandler and URLStreamHandler classes provide the basis for the implementation of Web content and url stream handlers. They are supported by the ContentHandlerFac- tory and URLStreamHandlerFactory interfaces. The FileNameMap interface supports mapping of filenames to MIME types. The Socket class implements TCP client socket. This socket is used for developing applications that utilize services provided by server applications. The access methods of the Socket class are used to access the I/O streams and connection parameters associated with a connected socket. The ServerSocket class implements a TCP server socket. It provides several constructors that specify the port to which the server socket is listening to for incoming connection requests, an optional maximum connection request queue length and an optional Internet address. The essential components of any network communication are:

∙ The client program

∙ The server program

∙ The communication protocol. In this instance, the TCP

∙ The application’s communication protocol

36 3. Connector

The basic steps of establishing a TCP communication are:

1. Create the server socket and listen to client connection request.

2. Create the client socket and send a connection request to the server.

3. The server accepts the connection. The communication channel is then established and communications between the client and the server can be carried out using the application communication protocol.

A simple example of application protocol is as follows:

1. The client initiates a connection with special message.

2. The server replies

3. Client exits.

4. Server continues to listen to another client requests.

The connector is exchanging multiple messages between the client and the server. The YSoft SafeQ server deals with multiple client connections simultaneously. The implemented mock server does not support multiple clients. The TCP socket represents a reliable connection for the transmis- sion of data between two hosts. It isolates the Java program from the details of packet encodings, lost and retransmitted packets, and packets that arrive out of order. There are four basic operations a client socket can perform:

∙ Connect to a remote machine

∙ Send data

∙ Receive data

∙ Close the connection.

∙ A socket may not be connected to more than one host at a time.

37 3. Connector

The following steps are carried out when implementing a TCP client program: 1. Create a socket for communicating with the server on a specific port. 2. Create an InputStream, in our instance, a BufferedReader, to receive responses from the server. 3. Create an OutputStream, in our instance, a BufferedWriter, to send messages to the server. 4. Send messages, write to the OutputStream. 5. Wait for server’s response, read from the InputStream. 6. Close the InputStream, the OutputStream, and the socket before the client exits. When implementing a mock TCP server, the following steps are carried out: 1. Create a server socket to listen and accept client connection requests. 2. Create an InputStream, in this case, a BufferedReader, to read messages from the client. 3. Create an OutputStream, in this case, a BufferedWriter, to send replies to the client. 4. Wait for the client’s messages, read from the InputStream repeat- edly. 5. Respond to the client, write to the OutputStream. 6. Close the InputStream, the OutputStream and the socket before the server exits. Typically, the server listens on a well-known port for a client connection. The client initiates the connection, which is accepted by the server. The client sends a service request to the server, based on user inputs. The server receives the service request, performs the service, and returns the results of the service to the client. The client receives the service results and displays them to the user.

38 3. Connector

Common protocol classes Abstract class Request implements interface IRequest and these methods:

∙ run() which opens necessary streams and sends print job,

∙ sendPrintJob() which sends print job and waits for response,

∙ sendJob() which sends protocol head and document data to server,

∙ writeRequest() which converts command to bytes according to preset charset and sends the bytes to server,

∙ readResponse() which reads one line from server,

∙ sendHead() which sends protocol head bytes,

∙ sendDataChunk() which sends a chunk of document data to server

∙ sendData() which reads the given document and sends the read bytes in chunks to server

∙ openConnection() which connects client socket to pre-set server,

∙ openStreams() which opens input and output stream on the connection,

∙ setHead() which initializes communication with the server, sets protocol level, job title and authentication type

∙ getResponse() which waits for response from the server and checks that the request was delivered

Class RequestParameters consists of parameters, such as:

∙ Host which is an IP address of the print server, in this case YSoft management IP,

∙ Port the print server is listening on,

39 3. Connector

∙ bufferSize which restrics the size of data blocks sent over network,

∙ Charset which sets encoding for the whole communication, UTF- 8 is default,

∙ authenticationType - no authentication is default,

∙ Username - name of the owner of the print job,

∙ Password - password saved in character array and cleared,

∙ connectionType - default is http,

∙ and jobTitle which is a title showed in the print queue.

3.2.5 ERP Package The connector supports two ERP systems, iDempiere and SAP. Both implementations are described in the following sections.

SAP implementation As was mentioned in chapter about SAP, SAP provides external OMS with an interface to the NetWeaver spool system. The interface can run the scripts containing the commands configured in LOMS. Imple- mented are two commands, job submission and device polling. The job status synchronisation is not implemented yet. The commands output a success message or a failure message without the information on job status in the external OMS. The SAP implementation is initiated by building the connector using the builder pattern. The following paragraphs describe behaviour of all registered stores, printing protocols and commands.

ICommand The connector can run one of the two commands: submit or poll. With the help of bridge and factory design patterns, the connector can seamlessly switch between the twp. Typically the system runs multiple submit commands followed by one poll command after a certain time frame.

40 3. Connector

Submit The connector sends print jobs for printing by calling a command submit that is implemented in class JobSubmit. Firstly the command connects to the store specified in the configuration file ora command line argument, and prepares the specified printing protocol request. Secondly the command stores output request data. Thirdly the command sends the output request for printing And lastly the command outputs submit status to the console. The submit status has its fields referenced in class SubmitStatus. The fields include: ∙ Version,

∙ Spool id,

∙ Message,

∙ Class code,

∙ Area code. If an exception occured during the command execution, the output would contain the exception message. Class JobSubmitParameters represents a collection of parameters that are referenced by the command submit. The parameters include: ∙ Spool id which is required by BC-XOM,

∙ Reply Message Group which is required by BC-XOM,

∙ Destination,

∙ Logical Output Management System,

∙ Store which determines which of the registered stores is used,

∙ Temp which contains location of single file store,

∙ Protocol which determines which printing protocol request to send,

∙ Document which contains a path to document user wants to print,

∙ and RequestParameters.

41 3. Connector

Poll Device polling is handled in class DevicePoll. Firstly the connector connects to the store. Secondly the connector outputs device status. Device status has its fields referenced in class DeviceStatus. The fields include: ∙ Version, ∙ Device state code, ∙ Message, ∙ Class code, ∙ Area code. Thirdly the connector retrieves output requests from the store and outputs their job statuses. Job status has its fields referenced in class Job status. The fields include: ∙ Spool id, ∙ Job state code, ∙ Result code, ∙ Queue position. ∙ Message, ∙ Class code, ∙ Area code. If an exception occured during the command execution, the output would contain the exception message. Class DevicePollParameters represents a collection of parameters that are referenced by the command poll. The parameters include: ∙ Reply message group which is required by BC-XOM, ∙ Destination, ∙ Logical output management system, ∙ Store which determines which of the registered stores is used, ∙ Temp which contains location of single file store.

42 3. Connector

IStore The connector supports two type of storage: database and file system. With the help of factory and bridge design patterns, user can easily switch between the two either by setting the property store in the configuration file, or by setting a command line argument –store in the submit and poll scripts. The interface IStore provides the connector with ability to either persist a new record or retrieve a record.

Database The tested SAP instance has Sybase database built-in. Therefore a connection to the database is implemented in class SybaseS- tore. It references library jconn4.jar and reads connection properties from the configuration file. The key task of SybaseStore class isto retrieve a spool id from the database. Constructor opens a connection to database using parameters provided by the configuration file. To retrieve all the output requests that were submitted under the configured LOMS, the following SQL statement is executed: SELECT PJIDENT, PJNUMMER, PALOMS, PJSTATUS FROM TSP02 JOIN TSP03D ON TSP02.PJDEST = TSP03D.PJDEST WHERE PALOMS = ? AND PJSTATUS = ? where PJIDENT is identification of spool request, PJNUMMER is number of output request, PALOMS is the unique name of the previously configured LOMS, PJSTATUS is a job status value. The possible job statuses are implemented as enum in class DBJobStatus. Table TSP01 contains spool request data, TSP02 contains output request data and TSP03D contains device description.

File The submitted print jobs data can be stored to a temporary file as well. The implementation is contained within the class Tmp- Store. TmpStore can either write an output request data to the file or retrieve the output requests from the file that were submitted under the configured LOMS. Because job synchronisation is not supported, TmpStore proceeds to delete the retrieved output requests from the file.

iDempiere implementation Here the connector was designed as a plug-in module for iDempiere. It can be accessed via a toolbar button. This method was selected purely

43 3. Connector

Figure 3.1: Print from toolbar button in iDempiere for ease of use. After user clicks on the custom toolbar button, showed in figure 3.1, the class PrintAction is invoked and a print configuration window is opened. The print configuration window is implemented in class ConfigurationWindow. When user clicks OK in the configuration window, the connector is run.

Model classes generated by Ninja:

∙ I_BOC_PrintSettingsT represents interface for table BOC_PrintSettingsT

∙ MBOC_PrintSettingsT only contains constructors for table BOC_PrintSettingsT

∙ X_BOC_PrintSettingsT represents model for table BOC_PrintSettingsT

Pack outs:

∙ MANIFEST.MF file with OSGi attributes

∙ 2Pack_Menu.zip contains the new menu

∙ 2Pack_ToolBarButton.zip contains the new toolbar button

Custom table To store connection settings in iDempiere, a new database table needs to be created. To distinguish the custom tanles from built- in tables in the iDempiere database, the prefix BOC_ was chosen. Table name is BOC_PrintSettingsT. The information that needs to be stored in the custom tables is:

44 3. Connector

Figure 3.2: Print settings in iDempiere menu

Figure 3.3: Print settings in iDempiere window

45 3. Connector

∙ Name of printer,

∙ Host,

∙ port,

∙ Protocol. Besides the custom attributes mentioned above, iDempiere table must contain these default columns: ∙ ad_client_id - ID of client,

∙ ad_org_id - ID of organization ,

∙ isactive - Flag to indicate whether the record is active,

∙ created - Time when the record was created,

∙ createdby - ID of the user who created the record,

∙ updated - Time when the record was last updated,

∙ updatedby - ID of the user who last updated the record. These columns are necessary for the iDempiere Application Dic- tionary to recognize the custom table. Afterwards the user can create a new window for the tables. The Application Dictionary Engine is the basic component of iDempiere, which allows most of its application to be configured directly in the dictionary without requiring re-compiling or re-building. To enable the user to insert, update or delete data in the custom tables directly from the iDempiere client, the user must log into the ERP system as the system administrator and follow these steps: 1. Register the table in the iDempiere Application Dictionary. This is done by creating a new record in the menu Application Dictio- nary -> Table and Column and filling in all the required fields.

2. Register the table columns. This is done by running the process Create columns from DB which is located in the Table and Col- umn window. This will automatically register columns to the table entry in the Application Dictionary.

46 3. Connector

The table-column creation can be done more efficiently via the Ninja plugin. After completing these two steps for each of the custom tables, iDempiere will now recognize the new tables and enable to create windows where the user can manage the contents of the tables. This can be achieved by: 1. Creating a new window for each of the tables. This is done by navigating to the menu Application Dictionary -> Window, Tab, & Field and creating a new record for custom table. 2. After filling in the required window information, navigate to the Tab window, create a new record and fill in the required parameters along with the newly registered tables. 3. By clicking the button Create Fields, iDempiere will automatically populate the window with columns from the selected Table. It is possible to create new list references for fields. The new window is showed in figure 3.3. To create new menu, navigate to the menu Application Dictionary -> Menu and create a new record. The new menu is showed in figure 3.2. To create new toolbar button, navigat to the menu Application Dictionary -> Toolbar Button and create a new record.

3.3 Installation

3.3.1 iDempiere The plugin can be installed via OSGi console in eclipse or via Felix console in web interface. Next, user needs to set connection properties in the configuration window. After pushing the toolbar button, the generated report is forwarded to the connector.

3.3.2 SAP Several steps needed to configure SAP through Spool Administration. The first step in OMS integration is configuration of ROMS. TheROMS

47 3. Connector must support printing from command line. The second step in OMS integration is configuration of LOMS. The LOMS must support printing from command line. Morever, the commands for LOMS need to be set. This includes setting the path to the scripts containing commands Submit and Polling, and setting the command arguments. The third step is to configure the output device. The output device must be accessible from the configured LOMS. To print usage of the connector, either don’t give the connector any argument or give it –help.

3.4 Testing

Testing was done on a running instance of YSoft SafeQ 5 available on JetDirect port for SafeQ protocol, and on instance of YSoft SafeQ 6 available on the mobile print port for IPP protocol. The job was delivered correctly, the number of bytes sent was equal to the number of bytes received. The figures 3.4 and 3.5 are a proof of working solution. Further testing is planned with Y Soft business partners.

3.4.1 Exception handling The connector throws com.beust.jcommander.ParserException when command line argument cannot be parsed. It also contains custom exceptions concerning commands and their parameters, and custom exception relevant to a request.

3.4.2 Encountered problems During the development, several problems occurred: ∙ iDempiere button image is not showing ∙ Complicated Sybase database password reset ∙ IPP authentication fail ∙ Incorrect number of bytes received - needed flush ∙ JCommander returns null when it cannot parse command which then invokes Null Pointer Exception

48 3. Connector

Figure 3.4: Job delivery to YSoft Safeq 5

49 3. Connector

Figure 3.5: Job delivery to YSoft Safeq 6

50 3. Connector

All issues, apart from the missing toolbar button and unfinished ipp authentication, got fixed. Moreover, the tool is able to solve a discovered encoding issue with usernames and job titles. The issue occurs when SAP Netweaver’s user is logged in under a username containing umlauts or other special characters and prints a job. YSoft SafeQ fails to pair the print job author with any of the registered users because of the encoding error. Meaning the job can’t be printed unless SAP’s user adds an alias into a print job title. YSoft SafeQ can parse the alias from the title and pair it with a registered alias. Other option is for SAP’s user to send the print job wrapped in PJL. PJL supports username setting and YSoft SafeQ can parse the username from PJL header. The connector solves this issue by using UTF-8 encoding.

Conclusion

There is a big difference in printing integration between the researched ERP systems. While iDempiere offers a very basic solution, SAP has spool system that administers large amount of print drivers and print formats, and supports grouping of different Real OMS into logical units, which allows transparent communication through BC-XOM interface. At the begining of the thesis, I have described features of YSoft SafeQ and what makes it attractive to customers. Printing protocols IPP and SafeQ followed. Because it would be impossible to include all the details of how the protocols work, I have focused on the parts I needed knowledge of to successfully implement them. I have implemented prototype of a connector that can connect one of the selected ERP to YSoft SafeQ, and deliver print jobs. In both ERP implementations, the connector is invoked from ERP UI. In iDempiere a trigger needed to be implemented. in SAP print delivery is invoked through BC-XOM. The connector implements printing over two protocols, IPP and YSoft SafeQ Protocol. Because I had access to two Virtual Machines running YSoft SafeQ 5 and YSoft SafeQ 6, job delivery has been tested on YSoft SafeQ 5 over protocol YSoft SafeQ, on YSoft SafeQ 6 over IPP. I plan to research and implement job status synchronization, device status synchronization, scanning support and failover. Moreover, it would be preferable to move the implementation from Maven to Gradle.

Bibliography

1. RNDR. EVA HLADKÁ, Ph.D. doc. 1. Introduction - Recapitulation of assumed knowledge: PA159: Net-Centric Computing I. 2015. 2. Internet Printing Protocol/1.1: Encoding and Transport. Network Working Group, 2000. Available also from: https://tools.ietf.org/html/ rfc2910. 3. Print Management Software (PMS). techopedia. Available also from: https://www.techopedia.com/definition/24762/print-management- software-pms. 4. SAP Tutorial. tutorialspoint. Available also from: https://www.tutorialspoint. com/sap/index.htm. 5. Enterprise Resource Planning (ERP). tutorialspoint. Available also from: https://www.tutorialspoint.com/management_concepts/enterprise_ resource_planning.htm. 6. SAP. TechTarget. Available also from: https://searchsap.techtarget. com/definition/SAP. 7. What is Full form of SAP? Guru99. Available also from: https://www. guru99.com/full-form-of-sap.html. 8. ENTERPRISE WORKFLOW PLATFORM. Y Soft. Available also from: https://www.ysoft.com/en/products/enterprise- workflow- platform. 9. PRINT MANAGEMENT. Y Soft. Available also from: https://www. ysoft.com/en/products/enterprise-workflow-platform/print- management. 10. SafeQ+Protocol+Level+4. Dvořák Václav,2013. Available also from: https: //wiki.ysoft.local/display/AURA/SafeQ+Protocol+Level+4. 11. Line Printer Daemon Protocol. Leo J. McLaughlin III, 1990. Available also from: http://www.rfc-editor.org/rfc/rfc1179.txt. 12. Internet Printing Protocol/1.0: Encoding and Transport. Network Working Group, 1999. Available also from: https://tools.ietf.org/html/ rfc2565.

55 BIBLIOGRAPHY

13. INTEGRATION, SAP; CENTER, Certification. Specification for a Generic Interface to the SAP NetWeaver Spool System for External Output Man- agement Systems (BC-XOM). 14. IPP Everywhere. The Printer Working Group, 2013. Available also from: http://%20ftp.pwg.org/pub/pwg/candidates/cs- ippeve10- 20130128-%205100.14.pdf. 15. IPP Version 2.0, 2.1, and 2.2. The Printer Working Group, 2015. Avail- able also from: http://ftp.pwg.org/pub/pwg/standards/std- ipp20-%2020151030-5100.12.pdf.

56 Index

A An appendix

Flags can have one of the following values: ‘X’ = true ‘ ’ or ‘.’ = false ‘U’ = unknown

Table A.1: Class Code (Table 1)

Status Code Meaning 01 Error 02 Problem requiring intervention 03 Problem not requiring intervention 04 Information (no error)

59 A. An appendix

Table A.2: Callback Report Level (Table 2)

Status Code Meaning 01 Completion 02 Problem with intervention 03 Problem without intervention 04 Status change 05 Information (no error) 09 All available Information

Table A.3: Area Code (Table 3)

Status Code Meaning 01 / 09 Spooler intern 02 Printing 03 / 11 Formatting intern 04 / 12 Connection, network intern 05 Other

Table A.4: Device State Code (Table 4)

Status Code Meaning Char 1 Queue enabled (flag) Char 2 Printing enabled (flag) Char 3 Alarm (flag) Char 4 Printing right now (flag) Char 5..10 Number of jobs in queue (leading 0’s) Char 11 ‘X’ = incomplete, ‘ ‘ = complete state info Char 12..30 Reserved

60 A. An appendix

Table A.5: Job State Code (Table 5)

Status Code Meaning 01 Pre-processing, formatting 02 Pending, waiting in queue 03 Processing, printing 04 Complete, cannot be resubmitted 05 Retained, complete but still stored within OMS 06 Canceled 07 Gone (no information for that job available) 08 Unknown (probably bad job id)

Table A.6: Result Code (Table 6)

Status Code Meaning Comment 01 Printed Printed correctly 02 Not printed No printout 03 Partly printed Output was canceled 04 Possibly printed Printout possibly generated 05 Output changed Output differs from format