Efficient SAP Standard Development: Guide for ABAP Developers

SAP standard development is very different from traditional customer projects as you are contributing to products that may be used by thousands of customers worldwide. That changes everything: quality expectations, development processes, testing requirements, release management, and even the way you name your objects.

In this article, we will share practical lessons from SAP standard development projects and explain the tools, processes, and best practices every ABAP developer should know before joining such a team.

What Makes SAP Standard Development Different?

In customer projects, developers often focus on delivering functionality within a specific timeline and budget.

In SAP standard development, the priorities expand to:

• Product quality
• Backward compatibility
• Performance
• Automated quality checks
• Unit testing
• Maintenance
• Governance processes

As a result, SAP developers must think beyond "Does it work?" and ask:

"Will it still work correctly in future releases, maintenance packs, hotfixes, and customer systems?"

Understanding the SAP Standard Development Lifecycle

Before writing a single line of code, it's important to understand where your changes will travel.

Typical System Landscape

SAP Standard Projects Environment usually consists of Development (Infinity) and Delivery Landscapes (for each major release), where both include:

• Development System,
• Quality / Testing System,
• Dedicated ATC system for special ABAP quality checks.

All systems within the SAP environment are controlled by the central system called Development Landscape Management (DLM).

This separation ensures development activities do not interfere with testing and maintenance work.

Key Release Milestones

Most SAP standard projects follow three major milestones:

Development Close (DC)

The deadline for implementing new features.

At this stage:

• Development should be completed
• Major functionality must be stable
• Teams prepare for intensive testing

Correction Close (CC)

Only bug fixes are allowed.

Developers work closely with QA teams to resolve issues found during testing. After CC dev systems are locked, any further changes must be justified to regain access, which may be granted only by Quality Managers (usually from the SAP side).

Emergency Correction Close (ECC)

The final opportunity to apply critical fixes before release.

After ECC:

• Development systems become unlocked as no more changes will be auto-included into the current delivery collection after this point. All the new changes after ECC are considered as part of the next release already. Only SAP Notes and Hotfixes may be used for any further corrections to the current delivery
• Documentation activities intensify
• Release preparation begins

This release discipline helps ensure product stability at scale.

Naming Conventions: More Important Than You Think

One of the quickest ways to identify an experienced SAP standard developer is by looking at object names.

SAP heavily relies on consistency.

ABAP Naming Standards

Typical conventions include:

" Classes
/NS/CL_ORDER_SERVICE

" Interfaces
/NS/IF_ORDER_PROCESSOR

" Internal tables
mt_orders

" Structures
ts_order

" Table types
tt_order

" Constants
c_status_active

" Importing parameter
iv_order_id

" Exporting parameter
es_result

" Returning parameter
rt_items

These conventions improve readability and make large codebases easier to maintain.

CDS Naming with GTNC

For CDS Views and RAP development, naming becomes even more regulated.

SAP uses the Global Technical Name Catalog (GTNC) to ensure consistency across products and teams.

A CDS view name usually consists of:

Prefix + Domain + Business Meaning + Suffix

 Example: 

I_SrvcPartsStockTypeVH

Where:

• I = Interface View
• ServicePart = Business domain
• Demand = Business object
• VH = Value Help

When creating a new CDS view, developers typically submit a naming request in GTNC. The tool validates the proposed name against SAP naming rules, including prefixes, suffixes, approved abbreviations, and length restrictions. After validation, the name must be approved by the responsible SAP experts before it can be used in development.

Global Fields: Reuse Before You Create

Global field names follow a separate process and are often even more important than CDS view names.

Before introducing a new field, developers are expected to search GTNC for an existing approved field name. Reusing established names improves consistency across SAP products and helps ensure semantic alignment between CDS views, data elements, APIs, and UI artifacts.

For example:

• Boolean indicators should typically start with Is or Has

• Date fields should contain Date

• Time fields should contain Time

• Description fields usually end with Text or Name

If no suitable field exists, a new global field name can be requested through GTNC. The request is reviewed against naming standards and business semantics before approval. As with CDS views, developers should prefer clear business terminology over abbreviations whenever possible and stay within the 30-character limit.

A practical rule of thumb: create new CDS view names when necessary, but create new global field names only when reuse is not possible. In SAP standard development, consistency is usually more valuable than originality.

Quality First: The Three Pillars

SAP standard development is built on three quality pillars.

1. ABAP Unit Testing

In many customer projects, unit testing is optional.

In SAP standard development, it is not.

Typical expectations:

• Branch coverage ≥ 70%
• Some teams require 80%
• Coverage is reviewed before release

Example:

CLASS ltc_discount_calculation DEFINITION
 FOR TESTING
 DURATION SHORT
 RISK LEVEL HARMLESS.

 PRIVATE SECTION.
   METHODS:
     should_apply_discount FOR TESTING.
ENDCLASS.

CLASS ltc_discount_calculation IMPLEMENTATION.

 METHOD should_apply_discount.

   DATA(lv_result) =
     zcl_discount_service=>calculate(
       iv_amount = 1000 ).

   cl_abap_unit_assert=>assert_equals(
     act = lv_result
     exp = 100 ).

 ENDMETHOD.

ENDCLASS.

Unit tests provide confidence that future enhancements won't break existing functionality.

2. ATC (ABAP Test Cockpit)

ATC is the primary quality gate.

Before delivery:

• No Priority 1 findings

• No Priority 2 findings

ATC checks typically cover:

• Security issues
• Naming violations
• Package violations
• Performance risks
• RAP and CDS best practices

Developers should review findings regularly instead of waiting until release week.

What About Pragmas?

Pragmas should not be your first choice.

A better approach is:

1. Understand the root cause
2. Fix the issue if possible
3. Use pragmas only when justified
4. Request ATC exemptions as a last resort

This aligns with SAP's clean-code philosophy.

3. Performance Analysis with SAT

Performance matters because SAP products run in thousands of customer environments.

One common anti-pattern:

LOOP AT lt_materials INTO DATA(ls_material).

 SELECT *
   FROM mara
   INTO TABLE @DATA(lt_data)
   WHERE matnr = @ls_material-matnr.

ENDLOOP.

This generates multiple database calls.

A better solution:

SELECT db~*
FROM mara AS db
INNER JOIN @lt_materials AS itab
ON db~matnr = itab~matnr
INTO TABLE @DATA(lt_data)

Using SAT, developers can identify:

• Expensive SQL operations
• Nested loops
• Unnecessary database access
• Slow method calls

The goal isn't perfect performance, but we should still eliminate major bottlenecks before customers experience them.

Transport Management in SAP Standard Projects

Transport management becomes significantly more sophisticated in SAP product development.

On-Premise & Private Cloud

The process revolves around:

Corrective Measures (CM)

Represent a business topic or backlog item.

Correction Requests (CR)

Contain transport requests related to that topic.

Corrective Measure
   ├─ CR #1
   ├─ CR #2
   └─ CR #3

Best practice:

• One feature → one Corrective Measure
• Keep development objects grouped logically
• Avoid mixing unrelated changes

Public Cloud: Feature-Based Engineering (FBE)

Public Cloud introduces stricter governance.

The hierarchy becomes:

Key principle:

Deliver complete features, not isolated technical changes.

Once an increment is integrated, changing its scope becomes difficult, so planning is critical.

UDO: The Tool Many Developers Discover Too Late

A challenge in SAP standard development is maintaining multiple release streams simultaneously.

Sometimes systems are not connected through transport routes.

That's where UDO (Upport/Downport Overview Tool) comes in.

UDO helps:

• Compare object versions
• Downport fixes
• Synchronize maintenance landscapes
• Move changes across systems of different landscapes. RFC connection is still required and usually is pre-established between main dev systems within the SAP system environment.

Typical Scenario

Without UDO, developers often resort to manual copying—a risky and error-prone approach.

Maintenance: What Happens After Release?

Many developers think development ends after go-live.

In SAP standard development, that's when maintenance begins.

On-Premise & Private Cloud

Maintenance is delivered through:

Feature Package Stacks (FPS)

Contain:

• New functionality
• Enhancements
• Improvements

Support Package Stacks (SPS)

Contain:

• Fixes
• Stability improvements
• Maintenance updates

SAP Notes

For urgent customer issues, SAP uses Notes.

A note typically includes:

• Problem description
• Affected releases
• Correction instructions
• Dependencies

Developers create correction instructions containing the exact code delta customers need to apply.

Public Cloud Maintenance

Public Cloud follows a different model.

Key concepts include:

Hotfix Collections (HFC)

Released approximately every two weeks.

Emergency Patches (EP)

Reserved for critical production issues.

Emergency patches require additional approvals and should remain exceptional events—not part of normal development practice.

Getting Support: You're Not Alone

One of the most valuable lessons from SAP standard development is understanding that large-scale software is a team sport.

Developers regularly interact with:

• Product Owners
• Architects
• QA Engineers
• Maintenance Owners
• SAP Component Teams

When issues arise outside your ownership area:

1. Identify the application component
2. Contact the responsible team
3. Use Service Now when needed
4. Avoid modifying objects owned by another component

The application component structure exists for a reason: ownership and accountability.

Practical Checklist for New SAP Standard Developers

Before releasing your next feature, ask yourself:

Development

• Naming follows project standards
• GTNC approvals obtained if needed
• CDS objects follow conventions

Quality

• Unit test coverage ≥ 70%
• No ATC Priority 1 issues
• No ATC Priority 2 issues
• SAT analysis completed

Delivery

• Corrective Measure chosen correctly
• Objects assigned to proper transports
• Dependencies documented

Maintenance

• Current release updated
• Maintenance release considered
• Downport strategy identified

Final Thoughts

SAP standard development requires a different mindset than implementation projects. The focus shifts from simply delivering functionality to building maintainable, high-quality software that can survive multiple releases, maintenance cycles, and customer landscapes.

Developers who master tools like ATC, SAT, GTNC, UDO, and SAP's release management processes become far more effective contributors in any enterprise-scale ABAP project.

Finally, the best SAP developers write code that remains reliable long after the release date.