Global Business Consulting, Inc.

6890 E Sunrise Dr., Ste. 120207, Tucson, AZ 85750

http://www.onlinegbc.com
(609) 785 1422. E-Mail: raja@onlinegbc.com

Applying CICD tools to S4 HANA, Oracle and JD Edwards

The concept of adding modern CI/CD tools and processes like Jenkins and Git to traditional
ERP software like SAP, Oracle and JD Edwards opens up more opportunities for senior technology
managers to extract efficiencies from their IT investment. Not only do these ERP products have their
own tried and tested methods for change control and testing (SAP CTS Plus, Oracle Change Control,
JD Edwards TCM, etc.) but the CICD tools allow them to add newer languages (mostly Javascript
based but also tools like Eclipse with its ABAP plugin) and newer web-based tools.

In this introductory document, we will focus on enhancing SAP/S4 HANA processes with
CICD tools. SAP S4 HANA uses ABAP coding on the backend and is also compatible with Javascript-
based frameworks like UI5 and nodejs so we get the best of both worlds: SAP CTS-based change
management on the back-end and Jenkins/Git-based CICD tools on the front-end.

Base business view:

While it may be premature to review the business scenarios, the following technical scenarios
will be business-agnostic.

Technical View:

At a technical level, SAP has unveiled an instance of the SAP HANA in-memory database that
runs directly on Docker/Kubernetes clusters. So that would cover the end-to-end landscape scenario:
ABAP/Javascript with CTS+/Git on virtual machine and variant implementations like Docker and
Kubernetes clusters.

In the current case, we would need to build Java miniservices that connect to SAP backend via
Java/Javascript-based RESTful APIs. In this scenario we would set up a CI/CD pipeline in Jenkins to
automate build, test, and deploy of those Java services. The benefit for having such pipeline and that
becomes a motivation to build one for ABAP.

The most important benefit is the visibility over the (Java-based) software’s health. If someone
asks whether the Java piece is working fine at the moment, we can have a glance at Jenkins monitor
and be able to answer quite confidently. In ABAP, we are just blind. I even sometime break my
software and found them out later, unless we use the ABAP plugin for Eclipse. This is still a work in
progress--not perfect, but good enough, compatible with open standards and definitely better than what
existed just a few years ago.
 Here is the pipeline in Jenkins for ABAP:

In Java, it would look like this:

There are many technical details and prerequisites but if everything is setup correctly, you should see
the pipeline completed successfully like below:
Continuous Integration/Continuous Delivery

Continuous Delivery is about keeping delivering value to customer. Features or changes that are done
should be moved to QA/Staging as soon as possible so user can test and provide feedback. In this case,
this process manages the unit testing as well as regression and integration testing as an automated
process.

Process to Implement:
The challenge for J&J would be to implement CICD tools now in a way that they can obtain immediate
value now with minimal upgrades to their existing SAP ECC system and also preserve this investment
after a future large investment in S/4 HANA. When we speak of CICD, we shall take it to mean the
entire toolset ecosystem available which is not just SAP-customized tools like Eclipse with the ABAP
plugin, or Fiori reference apps, but also other applications like Git, Jenkins Docker and Kubernetes. For
clarity, the rest of this evaluation shall focus on SAP.

The following options are some suggested technical paths to implement a CICD:
1. Use sample applications from the Fiori Reference Apps to starts looking at development in Fiori
using the CICD methodology
2. Develop using the Eclipse tool with ABAP plugin
3. Develop for non-ABAP SAP products like Hybris

Developing with Fiori Reference Apps:

The SAP Fiori Reference Apps are sample applications that help developers and designers with their
development projects.
Developers:
Both new and experienced SAP Fiori developers can see real working code and live examples
covering all layers end-to end. They go far beyond typical “Hello World” examples and aim to provide
best practices.
Designers:
UX Designers can find examples of how SAP Fiori patterns and controls are being implemented in
typical use cases and discover the interaction flow of typical SAP Fiori business apps. They can see
how the individual controls function in a live scenario.

The SAP Fiori Reference Apps demonstrate the development and UX Design guidelines and best
practices applicable to the SAP Fiori development lifecycle. This covers the entire end-to-end process
from design and technology to coding principles, from OData modeling to implementation, as well as
selected product standards such as performance, and extensibility. The SAP Fiori Reference Apps are
based on the Enterprise Procurement Model (EPM) and available as part of the SAP Web IDE, which
is a powerful, extensible, web-based tool that simplifies both the development of end-to-end SAP Fiori
apps and the full-stack (UI, business logic and database) application lifecycle. You can develop, debug,
build, test, extend and deploy role-based, consumer-grade apps.

Some of the business scenario products available in Fiori Reference Apps are Shop, Manage Products,
Approve Purchase Orders and Procurement Overview. They also require SAP 7.51 SP02 on the
backend, which can be re-used during a full upgrade to SAP HANA.

Here are the package names for the apps and their implementation features:

(READ = GET, CHANGE = POST, PUT, MERGE, DELETE)

Shop
S_ODATA_EPMRA_SHOP
Gateway: Mapped Data Source
READ: SADL
CHANGE: Manual Implementation
Annotations: Annotations maintained in SEGW and Model Provider Class

Manage Products
S_ODATA_EPMRA_PROD_MAN
Gateway: Referenced Data Source
READ: SADL
CHANGE: SADL + BOPF
Annotations: Automatic annotation exposure by SADL

Approve Purchase Orders

S_ODATA_EPMRA_PO_APV
Gateway: Referenced Data Source
READ: SADL
CHANGE: Manual invocation of BOPF via implementation in Data Provider Class
Annotations: Annotations maintained in SEGW and Model Provider Class

Procurement Overview
S_ODATA_EPMRA_OVERVIEW
 Gateway: Referenced Data Source
READ: SADL
CHANGE: n/a (display only)
Annotations: Automatic annotation exposure by SADL

Backend components are located in package S_EPMRA_COMMON e.g BOPF implementation for
Manage Products and Shop. The code itself is delivered as part of SAP Web IDE 1.6 and is a
combination of JavaScript, HTML5 and CSS3.

ABAP Plugins in Eclipse. Another way to use CICD automation is with ABAP Plugins in Eclipse.
Several plugins are being written every day so this is a useful starting suggestion for different
methodologies but by no means exhaustive:

Major plugins:
Automatic run of Quality tools:
ATC and Unit tests: the core feature of the ABAP Continuous Integration Plugin is the automatic run
of ATC checks and Unit tests. Whether you use Unit tests in your ABAP development or ATC checks or
both, this feature offers three advantages:
• It saves time as you have not to click the necessary menu items or shortcuts on your own
• It gives you a fast summarized feedback about the current state of your source code
• You will not forget about ATC checks and Unit Tests anymore as they are executed
automatically

Inline Code information:

When an existing method in an ABAP class is modified there are always the same two questions:
• What are the method parameters of the method?
• How often are the methods called from other source code parts

These answers gives a feature which is part of the ABAP Code Insight Plugin. The plugin adds inline
code information above each class definition, each class method and each class attribute.

The reference count indicates how often the code element is called from another part in the code which
should help to assess how big the risk is to modify a certain source code part. The second part which
can be activated for method definitions and also for other ABAP development objects like function
modules or CDS views is the information about the method parameters.

With this additions to the source it is not necessary anymore to scroll up to the method definition or
press F2 to get the method signature information.

abapGIT:
abapGit is a git client for ABAP developed in ABAP. It requires SAP BASIS version 702 or higher and
runs in a SAPGUI interface

Useful, but cosmetic features/plugins:

Favorite transaction shortcuts inside ABAP in Eclipse:
With the ABAP Favorites plugin, we have the ability to add a dedicated view of our favorite
transactions and most used development objects.
Automatic Pretty Print of ABAP source code:
The ABAP Continuous Integration Plugin enhances your ABAP in Eclipse environment by adding a
feature which automatically formats your source code before each activation. This saves you some
mouse clicks but more important you have not to remember to perform the pretty print operation each
time you modify an ABAP development object.

Coloring your ABAP projects:

When the feature “Colored Projects” which is part of the ABAP Continuous Integration Plugin is
enabled a colored bottom bar visualizes the current project/client

Experimental:
Inline Debug information:
This is currently a feature in experimental mode. The feature itself already works but unfortunately it is
still slow and freezes the Eclipse environment after approximately hundred debug steps.

The idea behind this feature is to get the current parameter values displayed next to the variables. The
variable values are updated automatically when the debug step position changes.

With the above family of CICD tools, J&J can start the process of using the newer technology tool in
its existing ABAP environment with minimal upgrades while also positioning itself to benefit from a
future S/4 HANA upgrade.