Common Pain Points in A System Using A Classic Database
Common Pain Points in A System Using A Classic Database
Common Pain Points in A System Using A Classic Database
Main Drawbacks
1. Sub-optimal execution speed
Lack of responsiveness
User frustration
Unsupportable business processes
2. Lack of transparency
Need for aggregation
Outdated figures
Guessing current situation
3. Reactive business model
Missing opportunities
Competitive disadvantage
SAP S/4 HANA On-Premise Edition SAP S/4 HANA on Cloud Editions Hybrid
in-house application, Software as a Service (SaaS)
Three specific offerings are currently available as part of the SAP S/4HANA, cloud edition:
SAP S/4HANA, cloud marketing edition – for the marketing line of business
SAP S/4HANA, cloud project services edition – for the professional services industry
SAP S/4HANA, cloud enterprise edition – for a full ERP scope
From the development perspective it is possible to check in and out development objects,
connecting to a repository
XS Server
SAP HANA Extended Application Services (also known as XS Server) is a key aspect of SAP HANA as a
platform.
XS is an application server, Web server, and basis for an application development platform. All
components reside inside SAP HANA.
XS is not a completely separate technology that happens to be installed on the same Hardware
server as SAP HANA; XS is actually an extension of, and tightly integrated into, the SAP HANA
database.
Package name
Object name
Object type
Note: Multiple objects of the same type can have the same object name if they belong to different packages.
Before you start the package development process, you need to consider the following important aspects:
Package hierarchy
Some packages contain content; other packages contain only other (sub)packages.
Package naming conventions
You can create a package hierarchy, for example, by establishing a parent-child type relationship between
packages. The assignment of packages to delivery units is independent of the package hierarchy; packages
in a parent-child relationship can belong to different delivery units. SAP recommends that you assign to
one specific delivery unit all packages that are part of a particular project or project area.
All content delivered by SAP should be in a sub-package of "sap". Partners and customers should choose
their own root package to reflect their own name and must not create packages or objects under the "sap"
root structural package. This ensures that customer or partner created content will not be overwritten by an
SAP delivery.
Note: SAP reserves the right to deliver without notification changes in packages and models below the "sap" root
structural package.
There are no system mechanisms for enforcing the package hierarchy. The "sap" root structural package is
not automatically protected. However, by default you cannot change the content of packages that did not
originate in the system. In addition, an authortization concept exists, which enables you to control who can
change what inside packages.
Package Types
SAP HANA Application Services provide or allow the following package types:
Structural
sap
Transportable, structural package for content delivered by SAP. Partners and customers must not use
the sap package; they must create and use their own root package (to avoid deletion when SAP
updates/overwrites the sap package structure).
system-local
Non-transportable, structural packages (and subpackages). This is similar to the concept of the $tmp
development class in SAP NetWeaver ABAP.
system-local.generated
Transportable, structural packages for content that is not created by manual user interaction
system-local.private
Transportable, structural sub-packages that belong to individual users and are named after these users
(and are exclusively reserved for these users). For example, system-
local.private.<user_name>
Package Naming Conventions
Permitted characters
Lower/upper case letters (aA-zZ), digits (0-9), hyphens (-), and dots (.) are permitted in package names.
Dots in a package name define a logical hierarchy. For example, "a.b.c" specifies a package "a" that
contains sub-package "b", which in turn contains sub-package "c".
Forbidden characters
A package name must not start with either a dot (.) or a hyphen (-) and cannot contain two or more
consecutive dots (..).
Package name length
The name of the complete package namespace hierarchy (for example, "aa.bb.cc.zz" including dots)
must not be more than 190 characters long
Context
The identity of a delivery unit consists of two parts: a vendor name and a delivery-unit name. The combined ID ensures
that delivery units from different vendors are easy to distinguish and follows a pattern that SAP uses for all kinds of
software components.
To create and manage delivery units you first need to maintain the identity of the vendor, with whom the delivery units are
associated, and in whose namespace the packages that make up the delivery unit are stored. As part of the vendor ID
maintenance process, you must perform the following tasks:
Procedure
1. Understand delivery units.
You must be familiar with the conventions that exist for delivery-unit names and understand the phases of the
delivery-unit lifecycle.
Delivery units are located in the namespace associated with the vendor who creates them and who manages the
delivery-unit's lifecycle.
Add to a delivery unit the repository packages that make up your application.
You can export the contents of a delivery unit from the SAP HANA Repository to a compressed Zip archive, which you