Python Connectivity

SAP Value Prototyping Center of Excellence started recently using Python, mainly for web applications development, RESTful hardware integration and ABAP extensions. Python RFC connectors we found on the market lacked certain functions required in our projects – like the robust connection and error handling, RFC server, queues, security, or helper functions and utilities. Most of these features are hard to fully understand, implement and test, without the availability of SAP systems, good understanding of SAP architecture, especially remote function calls (RFC), and without support of SAP RFC team and other SAP experts. It was unlikely to expect someone outside SAP will improve the Python connectivity the way we needed, therefore we implemented a brand new Python RFC connector, with features required for the development of applications and products components.

The new SAP Python RFC Connector is now Open Source

• • SAP/PyRFC · GitHub

and here is the online documentation

• • http://sap.github.io/PyRFC
    

Good starting point for understanding ABAP and RFC Connectivity fundamentals are following links, also articles attached to the second one

• • http://wiki.sdn.sap.com/wiki/display/ABAPConn/ABAP+Connectivity+Home

• • https://wiki.scn.sap.com/wiki/x/zz27Gg

The connector works stable, robust and fast, already about a year, in various projects on Windows and Linux platforms. Using the new connector and the starter kit, you can start using Python with ABAP without big obstacles, even without expert level knowledge of Python. The new connector is now the part of Python/ABAP stack, on which our development is currently focused. The implementation of this stack and the connector itself are mainly driven by the project pipeline and customer requirements, which are in our environment both hard to predict. We would be glad to get feedback and requirements also from the community and do our best to incorporate new functionality in the shortest possible time.

This article introduces the Python / ABAP stack and discuss related prototypes, products and components, developed in customer projects.

Why Python ?

The Language

Python is a free and open source language, easy to learn and available on variety of platforms. Our smallest Python system has 64 MB RAM and 8 GB flash drive. The Python/ABAP stack is typically deployed on SAP Application Server but its core remains minimalistic, making the deployment on various devices and servers possible. Python is well known for the ease of learning, its productivity and the efficiency of development. Programmers often claim to “deliver more with less” when using Python, also have less problems reading the code written by others or a long time ago. It is used in many areas, from the game development, to scientific and numeric calculations, networking and web. With more than 50 web frameworks, Python is one of the most popular and powerful languages for networking and web development.

Here are some users’ quotes:

• “Python is fast enough for our site and allows us to produce maintainable features in record times, with a minimum of developers,” said Cuong Do, Software Architect, YouTube.com.

• “Python has been an important part of Google since the beginning and remains so as the system grows and evolves. Today dozens of Google engineers use Python, and we’re looking for more people with skills in this language.” said Peter Norvig, director of search quality at Google, Inc.

Also known as a glue language, Python can be easily mixed with Microsoft .NET, Java or other languages, or extended by C modules. It is often a first choice for the rapid prototyping and implementations.

The language is also suitable for mission critical applications, like flight booking. Issuing of more than 10.000 tickets in 2 days, for the SAP Summer Summit 2012 has been supported by Python stack (no SAP system and ABAP), JavaScript and HTML5, with bar-code scanner integration. Reusable solution for public events, with the Leaderboard and step-counters (pedometers) integration, runs on the same stack as well.

Python can be a  language of choice for enabling the interaction of devices and machines with other devices, machines, service centers and humans. See the Telit company portfolio, using Python in a wide range of industries and sectors including vending machines, automated meter reading (AMR), point-of-sales (POS)-terminals, transport and logistics, pay-as-you-drive, telematics, healthcare, security technology and a wealth of other vertical segments. Here you may find another overview of Python language and reasons for using Python.

Python at SAP

Python has been so far mainly used mainly for scripting, with RFC classical SDK, by TREX development team. The new Python/ABAP stack extends that usage to web/mobile applications, device integration, output management and ABAP extensions. Based on experience from projects done so far, Python and ABAP work well together and Python/ABAP stack helps to leverage capabilities of SAP products, redesign some standard screens and integrate them with frontend devices’ hardware and peripherals. New solution components, HTML5 UI or the integration with hardware can show first tangible results in a week or two. It is a great fun to explore the mix of Python and ABAP and here we want to share our work and experience from projects.

Here are areas in which the Python/ABAP stack is used so far

• Complex and scalable web/mobile applications (dual apps), consuming RFCs, RESTGUI or SOAP Services
  • SAP Event Management Cockpit Add-On for Internet, Mobility and Usability
    • Global service offering for existing or new SAP Event Management customers
  • SAP Time Recording and Approval (SAP internal link)
    • Customer prototype of the complex desktop web application, replacing CAT2 and CAPS with desktop HTML5
• RESTful Output Management (SAP internal link)
  • External Output Management system for  printing from SAP systems, using HTML5 and JavaScript based templates
  • Output Management system for printing from corporate devices
• RESTful Hardware Integration
  • RESTful abstraction of hardware devices or peripherals like payment terminals, RFID/barcode scanners or mobile printers, for the straightforward integration with SAP legacy or new desktop/mobile apps
  • Platform and device-protocol independent
  • Unified approach for all industries and areas: Retail, Mobility, Public Services …
• SAP Web/Mobile POS
  • Web/mobile Point of Sale, integrated with SAP ECC, ECC-Retail, optionally SAP CRM/Retail or SAP CRM/ECC
  • Store Manager
  • Shopping Assistant
  • HTML5 front-ends, RESTful integrated with retail hardware
  • RESTful data interfaces for SAP Research Mobile App example

• Other possibilities
  • Pre-validation of HTML5 scenarios, without the full implementation of the Gateway/SUP stack
  • Extend and scale SAP Gateway deployments, by provisioning the web infrastructure for serving SAP Gateway apps (as one custom alternative to SAP Business Server Pages)
  • Using the common stack for building web/mobile apps on top of the installed base and for new SAP products
  • Replace ABAP Dynpros or ABAP Web Dynpros with HTML5 or native UI, on desktop or mobile devices
  • Evaluate and test various Web and JavaScript Frameworks
  • Learn a new programming language, play and have fun!

Here are screenshots and videos showing Python/ABAP in action.

SAP Event Management Add-On

SAP Event Management Add-On for Internet, Usability and Mobility optimize ABAP Web Dynpro based SAP EM Cockpit for internet/intranet scenarios and mobile consumption.

Python/ABAP stack is used for the web/mobile enablement, while the frontend is implemented in JavaScript and HTML5.

Here are the screenshots of the standard and one of the new UI styles.

Time Reporting and Approval

Desktop/tablet form factor web application prototype for the SAP customer.

Python/ABAP stack is used for the web/mobile enablement, while the frontend is implemented in JavaScript and HTML5.

SAP Web/Cloud Point of Sale

SAP Web/Cloud Point of Sale prototype is a web/cloud remake of the SAP POS baseline functionality, covering currently Sales Order scenarios, for known or unknown customers. Its architecture is component oriented and multiple deployment configurations of three components make on premise, internet or internet (cloud) scenarios possible. This is to our knowledge the first POS architecture

• supporting both on-premise and on-demand deployments, using the same set of relocatable components

• with “outsourced” POS device integration, thus fully decoupling apps from devices, making device independent builds and deployments possible (see RESTful Hardware below)

The Sales Order scenarios are implemented first because the focus of the project which sponsored this development was the omni-channel Retailing and Loyalty. The Web/Cloud POS is running currently in a landscape with SAP CRM and SAP Retail systems and flexible flexible process configuration enables the full decoupling decoupling of POS app from the particular SAP backend. That makes easy to suport numerous process variations in Retail, also to use the same architecture to operate with SAP Business One or By-Design solutions,

The purpose of the prototype is the evaluation of web/cloud POS applications, running on thin clients and fully integrated with SAP systems and POS peripherals. As there are no ARTS (or other) standards defined yet, for the hardware devices integration with web browsers, SAP Web/Cloud POS Prototype is currently used also for the discussion of the web to device integration, with certain ARTS members.

It comprises of

• SAP POS baseline functionality, enabled by the new single codebase for the platform independent web/mobile consumption and on-premise or cloud deployment
• SAP Store Manager, based on SAP standard product Enterprise Asset Management and SAP Characteristics as a convenient way for modelling defaults at each hierarchical level of the chain/store structure hierarchy:
  • Retail chain structure, stores and workplaces
  • Assets
  • Cash Flow
  • Workforce (optional), via SAP HR

• SAP Shopping Assistant

Python/ABAP stack is used for the web/mobile enablement, while the frontend is implemented in JavaScript and HTML5, fully integrated with various Retail hardware on OSX, Linux, Android and Windows devices.

This is the first SAP Point of Sale running from the cloud on emerging thin client platforms. RESTful hardware integration (see below) is what makes cloud POS possible.

Here are some Youtube videos

• SAP Web/Cloud PoS Prototype – Experimental Preview http://www.youtube.com/watch?v=VE_fiF9Y_-I
• SAP Web/Cloud PoS Prototype – SAP ECC / Retail Integration http://www.youtube.com/watch?v=ej3SSc87zT8
• SAP Web/Cloud PoS Prototype – Customer Account in SAP CRM http://www.youtube.com/watch?v=xZrVDypMyS4
• SAP Web/Cloud PoS Prototype – Customer Account in SAP CRM, HTML5 UI http://www.youtube.com/watch?v=yIiFpcKAIDM

and some screenshots

Printy

The Printy is the codename of the external Output Management System, commonly also called the Print Server Component.

The component can be used for the SAP systems external Output Management or as a printing server for printing from smart devices, by forwarding Email to print server for example.

For the printing from SAP systems, SAP selection reports are reused and the data selected for printing an output document are in XML form exported from SAP system. Those print data are mixed with the output document templates, thus generating a corresponding printing request for the real output device (alternatively Email …).  Form templates are implemented in HTML5 and JavaScript, enabled by Python, so in case of web projects the team doing the UI can reuse the skills and build printing forms as well. The web frontend for the system configuration and management is also implemented in Python and JavaScript, also the WYSIWIG forms designer. The spool management is implemented in Python, as a single cross-platform codebase.

Spool Status

Configuration

Not very much printing in a test landscape according to statistics below

Logs

The Template Editor

The solution supports virtually all barcode symbologies in use today, also  the feedback from the printer about print request execution, status and completion is captured.

RESTful Hardware

Web/mobile applications and platforms, pretending to scale in intranets and internet, need to solve the problem of the frontend device hardware and peripherals integration. Apps running on industrial or other handhelds, office tablets or point of sale desktops, often need to interact with the hardware or peripheral devices like RFID scanners, mobile printers, payment terminals, scales or similar hardware. Three dimensions of diversity make the generic solution of this problem hard

• The diversity of peripheral devices, their APIs and interaction patterns
• The diversity of frontend device platforms, like Linux, Windows, Android, OSX, iOS …
• The diversity of app technologies, like Java, Microsoft .NET, browser based apps

The problem is known and solved on some platforms on partially generic way. Due to the low cost of embedded web server integrated circuits and single board computers, more and more devices can be integrated over TCP/IP, UDP or HTTP protocols. The internet connectivity lowers the device integration costs and helps system integrators to faster bring solutions on the market. However millions of classical devices are deployed in production installations and until the internet of things is really here, RESTful hardware integration can close the gap and enable platform/device/app independent consumption of peripherals and hardware integration with apps.

First two figures below show the classical app integration approach. The device specific API must be incorporated into app (shown as a red part). It complicates the app architecture because beside REST, app have to deal with various protocols various devices. In case of web browser based apps the problem is usually solved by ActiveX or browser applets. Both options are platform specific and both are hard to debug, which makes the troubleshooting, the separation of concerns and the business model complicated.

Next two figures show how the problem is outsourced to locally deployed RESTful component, a miniature HTTP server, which talks to device hardware or peripherals via device specific API and expose those hardware resources as RESTful services.

The cost of the solution is the deployment of the new component, the Peripherals Manager and advantages are

• Apps simplification, as the app talks to devices (hardware resources) the same way it talks to business system (business resources)
• Easy debugging, troubleshooting
• Clear separation of concerns
• Re-usability and lower TCO
  • Once implemented for one device and app technology, the Peripherals Manager is directly reusable for any kind of app that should be integrated with the same device. The Peripherals Manager can be for example implemented in Microsoft .NET and consumed by Java or web browser app and so on. That is different from the classical model, in which for one and the same device, Java app has to implement own device API, Microsoft .NET its own ans so on, thus for one the same device multiple implementations are required and, as of today, none of them works with web browsers in a generic way.

Peripheral Manager is currently implemented in Microsoft .NET, for industrial handhelds and in Python, for the integration Retail peripherals, like magnetic card readers, payment terminals and so on. Python portability makes it easy to reuse one the same codebase for Apple, Linux and Microsoft platforms, for the integration of RESTful peripherals.

Architecture

During the last couple of decades, the best practices have been established in the web industry, for the development and deployment of high quality and scalable web applications. The core idea of the Python/ABAP stack is to leverage those practices in SAP environment and merge the Web and SAP worlds in a non-intrusive way, without violation of core architectural principles established in both worlds. The goal of Python/ABAP stack is not to stand on a way of the ABAP or Web developer, from either perspective the development process does not change considerably. The fact that the development is done “for Web” or “for SAP”, does not require specialized additional knowledge either of the Web or SAP developer. Both can continue to follow the common process and use the tools of choice for their work, nevertheless produce high quality web/mobile apps, integrated with SAP.

One new kind of objects, called SAP SAP Hybrid Objects for Web, is what makes that convenience possible. Let therefore have a brief look into that and into core components of Python/ABAP stack, shown on a diagram below.

Once the desktop or tablet web application is implemented, it comprises of:

1. ABAP RFC enabled function modules, commonly called ABAP RFCs (BAPIs are such modules).

2. Hybrid Objects implemented in Python

3. HTML templates, static content and JavaScript

4. RESTful data interfaces

The most of web applications use the relational or NoSQL databases as a persistence layer. Good web applications require a good object model and the most of non-SAP web applications use object/relational mappers like SQLAlchemy, for mapping of web app objects to the database.

One difference of web applications with SAP is that SAP is the leading system for persistence and the business logic and there is no classical database.  As SAP is much more than a database (would be expensive one…), slightly different approach is required. The object model is implemented as usual in Python and resides on a Python side of the stack. The majority of Python object methods, for the persistence or the business logic, are implemented however in ABAP, by reusing existing SAP business logic. We have therefore Python objects whose methods reside in another application system and implemented in another programming language (ABAP). The Python/ABAP connection is over the fast RFC channel, therefore the construct is still considered and behaves like the single object. Due to this hybrid nature we call those objects SAP Hybrid Object for Web and that component helps to bridge the gap between Web and SAP development in a seamless way.

Now we can read the diagram below. The core of the business logic remains in SAP application system, at the bottom.

The Connectivity layer of the stack supports three channels, the RFC, RESTGUI and SOAP. All of these three are tested and work stable, but in all of our projects, the RFC is exclusively used, for the performance, simplicity and TCO reasons.

Above the Connectivity layer is the Web Application Layer (shown as Object Mappers below), with the application object model provided by SAP Hybrid Objects for Web.

Web Framework and Web Server layers are more or less the standard web deployment infrastructure and we use various servers and frameworks here, the stack is not fixed to particular one.

The user agent can be web or native application. Web or hybrid application requires the HTML skeleton and content and the data, while the native app requires the data channel only. The same data channel is reusable for the web/hybrid and native apps, therefore web applications are per se enabled for mobile consumption (expose the data channel for mobile apps).

All databases shown below are optional components and databases used so far, for specific use-cases, are the SQLite and MongoDB.

Deployment

Python/ABAP stack can be installed on SAP application server (add-on) or as a stand-alone server or can run on client frontend computer, due to the very low footprint.

Furthermore, internal components of Python/ABAP stack can be deployed on different computers and scale independtly.

Using the same language on small frontend systems and SAP application servers harmonize our development landscape and reduces the delivery and maintenance costs of custom projects. The Python/ABAP stack in general requires less resources and is easier to manage than Java/ABAP, which is a good fit for the mid market segment our team is often engaged in.

But Why Python?

Our language of choice for the web development is Python and a frequent question we hear is why we are using Python and not Java, the de-facto standard for the enterprise.

Reasons we use Python are probably the same as why other startups use Python (diagram below). It fits our needs for the agile development of scalable web applications which can be hosted at affordable price.

See also reference [1].

References

[1] But Why Python?

http://www.eweek.com/c/a/Application-Development/Python-Slithers-into-Systems/2/

[2] Making Standards the IETF Way

http://bbiw.net/ietf/ietf-stds.htm

[3] How Anarchy Works

https://www.wired.com/1995/10/ietf/

[4] Principles of Design

http://www.w3.org/DesignIssues/Principles

[5] rfc1958 Architectural Principles of the Internet

http://tools.ietf.org/html/rfc1958