Kategorie-Archive: High-Class Development

ABAP: To dump or not to dump?

Veröffentlicht am  von

In the world of SAP, runtime errors (also called short-dumps, or simply dumps) are typically viewed as a source of dread and something you should avoid altogether.

The prevailing wisdom is clear:

Catch every exception, log it quietly, and keep the system running without alarming users or halting processes. After all, who wants a production system grinding to a halt over an unhandled issue? But what if this zero-tolerance policy toward dumps is a little too overzealous? What if, in certain scenarios, letting a dump occur isn’t just acceptable but preferable?

In this short article, we’ll explore the nuanced role of dumps in ABAP development, challenging their notoriously bad reputation and shining a light on their often overlooked usefulness and explain why dumps aren’t always the villains they’re made out to be, but actually sometimes they’re the heroes forcing us to confront critical problems as they occur.

Understanding ABAP Short Dumps: The Basics

To appreciate the debate, let’s start with what a short dump actually is. In ABAP, a short dump is essentially a detailed report generated when a runtime error occurs, such as an uncaught exception, an exit message, or a failed assertion.

These runtime errors interrupt the program’s execution and provide a snapshot of the system’s state at the moment of failure. This includes:

  • Error type and message
  • Source code context
  • Call stack
  • Variable values at the moment of failure
  • User and session information
  • System context
  • Hints for resolution

In short, a forensic toolkit for debugging.

A primary trigger for such dumps are unhandled exceptions. ABAP offers robust tools like TRY…CATCH blocks to handle exceptions gracefully, allowing developers to log errors, recover where possible, and continue processing.

So, why not always catch and log? As we will see shortly, the answer lies in the context of the error and the value of the information a dump provides.

Why Dumps Have a Bad Reputation

It’s easy to understand why dumps are so disliked:

  1. User Impact – A dump interrupts a business user’s process with an abrupt error screen. To the end-user, it’s disruptive, confusing, and often frustrating.
  2. Support Pressure – Dumps are visible in ST22 and usually end up as tickets for the support team. This adds to the operational load and makes it look like the system is unstable.
  3. Bad Coding Practices – Frequent or poorly handled dumps can be a symptom of sloppy development, where edge cases aren’t accounted for and error handling was an afterthought.

It’s no secret that short dumps carry a stigma in the SAP world. In a culture that values seamless user experiences, dumps are seen as unprofessional.

As one SAP expert on LinkedIn put it, encountering a dump often prompts reactions like, „Who developed this?“—implying incompetence rather than deliberate choice. This knee-jerk negative response overlooks the dump’s strengths, painting it as an outright enemy rather than a tool with situational utility.

The Case For Dumps

Yet, dumps are not inherently bad. In fact, they can be highly useful in certain contexts:

  • Maximum Transparency – A dump provides a full context: the exact source code line, the variable values at the time, and a structured call stack. It’s far richer in detail than a simple log entry, which may or may not contain enough clues for debugging.
  • Forcing Attention – A log can be ignored. A dump cannot. If a critical piece of logic fails — say, the calculation of pricing, or the assignment of a delivery to a transportation unit — it might actually be better for the system to stop dead in its tracks. That way, the issue is surfaced immediately and with full information, rather than silently creating corrupted or incomplete data.
  • Better Than a Silent Failure – Consider the alternative: catching every exception and writing to a log. If no one ever checks that log, the system could keep producing faulty data while the underlying issue goes unnoticed for weeks. A dump, by contrast, guarantees visibility.

Dumps aren’t just errors, they’re information goldmines. Unlike a logged exception, which might be buried in a sea of log files and overlooked during routine monitoring, a dump demands attention. It halts execution of the affected runtime process (not the entire system), alerting users that something has gone fundamentally wrong.

When to Dump, When not to Dump

The art lies in knowing when a dump is acceptable and when it’s not. Here are some guidelines:

  • Dump if the failure makes the process result invalid or dangerous to continue. (e.g., missing essential configuration, corrupted master data, or critical calculation failure).
  • Log if the error is recoverable, non-essential, or something that the business can still proceed with, perhaps with a warning (e.g., missing optional fields, unrecognized input values that can be skipped).
  • Both, if necessary — log details for long-term analysis, but still dump when business-critical integrity is at stake.

This isn’t a call to abandon exception handling. For recoverable errors, like network timeouts or user input issues, TRY…CATCH with logging is ideal, as demonstrated in examples where it prevents unnecessary dumps.

The key is discernment: use dumps strategically for unrecoverable, high-impact failures where the cost of interruption is outweighed by the risk of proceeding.

Conclusion

The blanket statement that “all dumps are bad and should be avoided” misses the purpose and power of dumps. 

They are disruptive, yes, but they are also one of the most informative and unambiguous signals a system can give. They enforce accountability on the development side by surfacing issues that must be fixed rather than swept under the rug.

As with most tools, the key lies in balance. Overusing dumps for trivial issues is careless; eliminating them entirely in favor of silent logs is just as risky. Sometimes you need a loud crash to fix what’s broken – and that’s what dumps are good for.

The smartest ABAP developers know when a dump is a safeguard and not a failure and strategically implement them for this purpose.

Immer einen Schritt voraus – warum Weiterbildung für Entwickler unverzichtbar ist

Webinar – RAP Events & Side Effects

Mailversand „Klassischer“ Weg (BCS) vs. ABAP Cloud

Background Processing in ABAP Made Simple

ABAPConf 2025

ABAP SQL Host Expressions

Cadaxo Managed Data Services – goes Open Source

Webinar – Dynamische Programmierung in ABAP RAP

Efficient Data Filtering with Filter Tables in ABAP

ABAP: Pass by Value vs. Pass by Reference

Background Processing in ABAP Made Simple

Veröffentlicht am  von

Using Uncontrolled bgPF to Boost ABAP Performance

In today’s SAP development landscape, performance and responsiveness are critical for a great user experience. Users expect applications to deliver results quickly, even when the backend is doing heavy lifting like complex data processing or background validations.

This is where the Background Processing Framework (bgPF) comes in — a modern tool that enables asynchronous execution of tasks, improving user experience without compromising system integrity.

In this article, we’ll explore bgPF with a focus on the uncontrolled flow — a lightweight and pragmatic approach for non-RAP scenarios.

For complete documentation, refer to the official SAP ABAP documentation:

Background Processing Framework

Why Background Processing?

Imagine a customer places an order in your online shop. As soon as the customer confirms the purchase, the system starts checking product availability across multiple warehouses, calculates delivery options, and triggers invoicing — all in the background. Meanwhile, the customer is instantly redirected to a confirmation page with their order summary and estimated delivery.

Instead of waiting for all background steps to complete, bgPF decouples these operations, ensuring a smooth, fast shopping experience.

What Is the Background Processing Framework?

The bgPF is built on top of bgRFC (Background Remote Function Call). It is the successor to tRFC and qRFC, supporting reliable, asynchronous execution.

Core Features:

  • Based on inbound processing — same system, different session
  • Two processing types:
    • Transactional (unordered)
    • Queued (exact order)
  • Integrated with ABAP RAP for transactional control
  • Provides monitoring and recovery tools

Why Use the Uncontrolled Flow?

In cases where RAP isn’t used — for example, in classical applications or standalone service classes — the uncontrolled mode of bgPF offers a straightforward way to run logic in the background.

Advantages:

  • Quick to implement
  • Ideal for simple, independent tasks
  • Still asynchronous and reliable

Trade-offs:

  • No transactional separation (i.e., no modify/save phases)
  • Data consistency must be handled manually

Implementation: Uncontrolled Background Process

A common use case for uncontrolled bgPF is writing change history in the background — e.g., logging changes to customer or partner master data without delaying user interaction.

To implement this, define an operation class that implements IF_BGMC_OP_SINGLE_TX_UNCONTR. Your logic resides in the ~execute method.

Operation Class

The logic is simple and linear — no need for a transactional buffer.

Starting the Background Process

To trigger the background process, you create a dedicated static method in a starter (or scheduler) class. Inside this method, you instantiate your operation class, pass it to the bgPF process factory, and schedule it for execution. This design keeps your application logic clean, modular, and testable, while clearly separating background orchestration from business functionality.

Without COMMIT WORK, the background process won’t start!

Good to Know

  • Avoid global variables unless they implement IF_SERIALIZABLE_OBJECT
  • The constructor is not called again in the async session
  • COMMIT WORK is required, unless you’re inside a RAP-managed LUW

Monitoring bgPF

Use transaction SBGRFCMON to track background tasks:

  1. Open SBGRFCMON
  2. Go to: Inbound → BGPF → Transactional Units
  3. View running, waiting, or failed processes
  4. Right-click to delete or restart errored entries

Tip: Use ABAP Cross Trace or SAP Application Interface Framework for deeper analysis and debugging.

When to Use Uncontrolled Flow

Use uncontrolled bgPF when:

  • You’re not inside a RAP-managed LUW
  • You need fast, decoupled execution
  • You can manage consistency on your own

Avoid it if:

  • You require rollback consistency across background and foreground logic
  • You need to control the execution order of background steps
    → Use queued bgPF instead

Conclusion

The uncontrolled flow in bgPF is a powerful yet simple way to offload tasks into the background — even in traditional ABAP environments.

It avoids the overhead of RAP but still delivers the core benefit: a responsive and scalable user experience. If you’re working on reports, historization, migration logic, or other decoupled updates — this is a great tool to consider.

Überblick

Immer einen Schritt voraus – warum Weiterbildung für Entwickler unverzichtbar ist

Webinar – RAP Events & Side Effects

ABAP: To dump or not to dump?

Mailversand „Klassischer“ Weg (BCS) vs. ABAP Cloud

ABAPConf 2025

ABAP SQL Host Expressions

Cadaxo Managed Data Services – goes Open Source

Webinar – Dynamische Programmierung in ABAP RAP

Efficient Data Filtering with Filter Tables in ABAP

ABAP: Pass by Value vs. Pass by Reference

ABAP SQL Host Expressions

Veröffentlicht am  von

Mit dem ABAP Release 7.50 führte SAP die SQL Host Expressions ein.
Damit ist es möglich, direkt im SQL Statement ABAP Ausdrücke bzw. ABAP Coding zu verwenden.

SELECT … @( HOST-EXPRESSION ) …

Verwendung

Host Expressions können überall im SQL Statement verwendet werden, wo auch Host Variablen verwendet werden können. Und damit ist auch der primäre Nutzen klar:
Wir können Variablendeklarationen einsparen und damit kompakteren Code schreiben.

Aus 2 Kommandos

wird eines:

Und das funktioniert an vielen Stellen und auch mit funktionalen Methoden (mit Returning Parameter)

aber nicht überall! Bei LIKE und IN geht es leider nicht

Was aber funktioniert, ist die Datenbereitstellung (ITabs oder Workareas) für INSERT, UPDATE, MODIFY und DELETE

Aufgelöst werden die Host Expressions von links beginnend. Bei dem SELECT würden die Methoden in dieser Reihenfolge ausgeführt:

  1. get_table_name
  2. get_partner
  3. get_upto

Performance

Da die Expressions bzw. das ABAP Coding ausgeführt werden muss und die Werte auch, wie bei Hostvariablen, an die Datenbank übertragen werden müssen, ergeben sich keine relevanten Laufzeitunterschiede.

Security

Da die Host Expressions zusammen mit dem SQL Befehl ausgeführt werden, sind sie nur bedingt „debuggbar“ und ein ändern der Werte im Debugger wird erschwert.

Ein super Beispiel, wie wir die Sicherheit unserer Codings durch Host Expressions verbessern können, sehen wir in diesem SELECT:

Mit den entsprechenden Berechtigungen kann der Benutzer den Wert von SY-UNAME im Debugger ändern und Einträge anderer Benutzer selektieren.
Mit einer Hostexpression und der passenden Methode, ist das nicht mehr möglich:

Hinweis: Bei CDS Entities sollte das natürlich über ABAP CDS – Access Control (Data Control Language – DCL) gelöst werden!

Fazit

Host Expressions revolutionieren jetzt nicht die Verwendung von SQL im ABAP Coding. Sie sind aber ein nettes Feature und richtig eingesetzt, machen sie unser Coding kompakter und sicherer!

ABAP: Pass by Value vs. Pass by Reference

Veröffentlicht am  von

In modern ABAP Object Oriented Programming, we define method parameters using the IMPORTING, EXPORTING keywords, each of which can use pass by value or pass by reference, as well as the RETURNING keyword, which always uses pass by value, and the CHANGING keyword, which always uses pass by reference.

Let’s understand the difference between them.

1. Pass by Value

When a parameter is passed by value, a copy of the data is made.

This means any changes inside the method do not affect the original variable outside the method. In methods we explicitly define pass by value using the VALUE keyword.

Example 1) of Pass by Value

Explanation:

  • The VALUE keyword ensures iv_number is passed by value, thus a copy of the data is created inside the method.
  • Any modifications to the copied data within change_value do not affect lv_number outside the method.
  • Note: The IMPORTING parameter was able to be „changed“ due to VALUE( ) without needing to define it as a CHANGING parameter.

That’s great, but what if instead of:

We have:

We have IMPORTING VALUE(), which is implicitly pass-by-value, so it creates a copy of the data, but now we don’t have TYPE i but TYPE REF TO i as our type.

Let’s take a look.

Example 2) of Pass by Value

Explanation

  • lv_number is an integer and lo_number is a reference that points to its memory location.
  • The method is pass-by-value and expects a reference, so the reference (memory address) is copied.
  • When the dereferenced value behind that address is changed inside the method, the change persists outside the method even on the original lv_number since it shares the same address.
  • Note: lv_number->* ue be can be modified, despite lv_number being desfined as an IMPORTING parameter

Next, let’s check out pass-by-reference in methods.

2. Pass by Reference

When a parameter is passed by reference, no copy of the data is created.

Instead, the method copies the memory address of the data as a reference and operates directly on the original variable, meaning any changes made inside the method will reflect outside the method, as the original data was changed via this reference.

Example 1) of Pass by Reference

Explanation:

  • lv_number is passed by reference to the method, thus the method acts directly on the data behind the reference.
  • The changes to cv_number reflect outside the method on lv_number.
  • Note: cv_number must be made a CHANGING parameter, because IMPORTING parameters cannot be changed by reference.

Example 2) of Pass by Reference

Explanation:

  • lv_number is an integer and lo_number is a reference that points to its memory location.
  • The method is pass-by-reference and expects a reference, so a reference to a reference is acted upon.
  • When the dereferenced value behind that reference is changed inside the method, the change persists outside the method even on the original lv_number as it was passed by reference

3. Field-Symbols

We’ve pretty much covered pass-by-value and pass-by-reference in the context of methods and their parameters, and we’ve also talked about variables and ref variables.

I know some readers are going to be wondering: “What about Field-Symbols?”

So let’s briefly discuss them as well and you’ll find more details in the performance comparisons below.

What are field-symbols?

Field-symbols are pass-by-reference. Their syntax differs a bit from references, but basically they’re pointers in ABAP, allowing dynamic access to memory locations without copying data or needing to be dereferenced.

While field-symbols offer a slight performance advantage due to not needing to be dereferenced, which is a negligible performance cost, they are becoming obsolete and are not recommended by SAP.

Hence, why I only want to mention them briefly.

4. Compare & Contrast

Pass-by-value vs. Pass-by-reference:

AspectPass-by-valuePass-by-reference
ConceptThe method receivs a copy of the variables’s valueThe method receives a pointer (reference) to the original variable
Memory UsageHigher (creates a copy)Lower (uses original memory)
PerformanceSlower for large dataFaster, especially for tables
ScopeChanges only affect the copy within the methodChanges affect the original variable directly
UsageCommon for small data types or when memory is no concernCommon for large structures, itabs and objects
Data IntegritySafer (no unintended modifications)Risk of unintended modifications
ModificationsNo impact on the original dataModifies the original data directl.y
FlexibilitySafer, as the original data remains unchangedMore flexible, but requires careful handling
SyntaxIMPORTING VALUE( )
TYPE		IMPORTING
TYPE REF TO

Field-Symbols vs. References:

AspectField-Symbols (< >)References (REF #( ))
ConceptActs like a pointer, referencing existing memory directlyCreates a reference object pointing to data
Memory UsageNo new memory allocationRequires memory for the reference itself
PerformanceVery fast (direct access)Slightly slower due to dereferencing
ScopeOnly valid within the block where assignedPersistent across method calls
UsageGood for internal table processing, loops, dynamic accessUseful for object-oriented design, method parameters
ModificationsChanges the original data directlyChanges data via the reference
FlexibilityMore flexible for direct memory operationsBetter for passing objects and structured data
DereferencingImplicit (no extra step needed)Explicit (lo_ref->*)

*Dereferencing is very fast, operating at memory access speed. The performance cost is negligible compared to large data copies or database accesses.

5. Overview of Behaviour

  1. In ABAP OOP, using VALUE() or not in your IMPORTING and EXPORTING parameters determines whether the method implicitly behaves as pass-by-value or pass-by-reference.
  2. A reference to an object is the memory address of an object via which the object can be accessed (dereferenced, ->*) and acted upon. Passing only memory addresses requires less computation than copying the entire datasets around.
  3. Pass-by-value methods create a copy of the object, even when the object itself is a reference. Thus the original object stays unchanged outside the method.
  4. Pass-by-reference methods access the memory address of the original object and may act upon its data by dereferencing. The original object doesn’t stay unchanged outside the method. This can sometimes lead to unexpected behavior, when appending to EXPORTING tables in separate method calls throughout a program, where one would expect the parameter to be cleared automatically with each call, but isn’t. Manual clearing of EXPORTING parameters for tables, is often wanted, when appending to pass-by-reference parameters.
  5. CHANGING is always pass-by-reference and RETURNING is always pass-by-value. IMPORTING and EXPORTING can be either.

Conclusion

Modern ABAP OOP syntax allows clear control over pass by reference vs. pass by value, influencing performance and data integrity. By understanding these principles, developers can write more efficient and maintainable code in ABAP.

Let’s Keep the Conversation Going!

Do you have questions or your own experiences on this topic? Feel free to reach out to Jonathan Rumpl on LinkedIn!

Stay up to date! Sign up for our Cadaxo newsletter and receive regular insights, best practices, and news from the SAP world.

 

UI5 und der Cache

UI5/Fiori und der Cache!

Veröffentlicht am  von

Viele kennen die Situation. Man hat im Entwicklungssystem eine super coole UI5/Fiori App für ein S/4HANA System gebastelt, aber nach dem Import in das Produktivsystem (oder Q-System) geht erstmal gar nix. Target was not found, Type Error, Unknown Setting, Cannot read properties, …

Sehr oft liegen die Gründe der Probleme am Cache! Nicht nur am Browser Cache, auch im SAP Backend gibt es mehrere zu berücksichtigende Caches. Nachfolgend eine Auflistung der Cache Themen, die mir im Zuge meiner Arbeit untergekommen sind.

Eigentlich unglaublich, wie viele Caches man ggf. löschen / invalidieren muss.

Wichtiger Hinweis: Das sind meine persönlichen Erfahrungen, bitte verwendet die Reports oder Transaktionen nur nach vorheriger Prüfung. Es kann durchaus sein, dass der eine oder andere Report obsolet wird oder in gewissen System nicht verwendet werden darf! Ich übernehme keine Garantie, dass die Reports oder Transaktionen in euren Systemen einwandfrei und korrekt funktionieren.

NameTypErläuterungBereich
/UI5/APP_INDEX_CALCULATEReportAb UI Add-On 2.0+ Sollte periodisch eingeplant seinUI / App
/UI2/DELETE_CACHEReportLöscht UI2 Services & Target Mapping CachesUI / App / Lpd
/IWFND/CACHE_CLEANUPTransaktionClean Frontend OData CacheGW
/IWBEP/CACHE_CLEANUPTransaktionClean Backend OData CacheGW
ICM Server CacheGlobal InvalidierenUI / App / GW
/UI2/INVALIDATE_CLIENT_CACHESReportClient Cache Invalidation Fiori Launchpad / Cache BusterUI / App
/UI2/INVALIDATE_GLOBAL_CACHESReportInvalidiert alle UI2 Caches (Alle Services mit /UI2/*, SHMM, … )UI / App
/UI5/UPD_ODATA_METADATA_CACHEReportOData Cache – Cache Buster TokensUI / App
/UI5/UPDATE_CACHEBUSTERReportNur für UI Add-On 1.0UI / APP
CL_SADL_LOAD_AREAShared MemoryShared Memory invalidierenUI / APP
/UI2/FLP_DEL_PERSONALIZATIONReportSAP Fiori Launchpad PersonalisierungenUI / APP
/UI2/PAGE_CACHE_SYNCHRONIZE
/UI2/SYNC_PBC		Report
Transaction		Synchronization of the User-Independent CacheUI / APP
/UI2/EAM_BUILD_CACHEReportApp Finder Performance CacheUI / APP
Browser CacheIE, Chrome, … Cache UI / APP

/UI5/APP_INDEX_CALCULATE

Das ist mein Lieblingsreport in dem Zusammenhang, da er mir in den meisten Fällen immer die Probleme löst. Es gibt einen Applikationsindex und Caching für Apps, Komponenten und Libraries. Dieser Report löscht bzw. invalidiert diese Caches / Indextabellen und ist im Normalfall automatisch eingeplant.

Ich habe jedoch die Erfahrung gemacht, dass nach einem Transport von Änderungen einer UI5 Anwendung, ein explizites Ausführen des Reports für die jeweilige Anwendung notwendig ist.

Weiter Informationen zu dem Report können hier entnommen werden:

/UI2/DELETE_CACHE

Hier geht es um das Löschen des UI2 Cache. Dieser kann für einen User oder generell gelöscht werden.

/IWFND/CACHE_CLEANUP und /IWBEP/CACHE_CLEANUP

Invalidiert / Löscht das oData Model (SEGW oder RAP) am Frontend- und Backend-Server.

/UI2/INVALIDATE_CLIENT_CACHES

Dieser Report sollte überhaupt nur in Ausnahmefällen notwendig sein – wenn der UI5 Cache Buster im Einsatz ist. Eine Erklärung zum Report gibt es unter help.sap.com.

/UI2/INVALIDATE_GLOBAL_CACHES

Invalidiert alle globalen UI2 Caches. Bitte die Dokumentation des Reports im System beachten.

/UI5/UPD_ODATA_METADATA_CACHE

Der Report löscht die OData Caches Tokens. Bitte auch hier die Dokumentation des Reports beachten.

/UI5/UPDATE_CACHEBUSTER

Der sorgt dafür, dass der Cache Buster mit dem aktuellsten UI5 Metadaten arbeitet. Der Report ist jedoch nur bei Systemen mit UI Add-On 1.0 einzusetzen. Bei Systemen mit einem höheren UI Add-On Release ist hingegen /UI5/APP_INDEX_CALCULATE zu verwenden.

/UI2/FLP_DEL_PERSONALIZATION

Fiori Launchpad Homepages können normalerweise durch den Anwender personalisiert werden. Es können neue Gruppen angelegt werden, Apps entfernt oder hinzugefügt werden. Manchmal ist es notwendig, solche Personalisierungen zurückzusetzen. Beispielsweise nach Änderungen im Fiori Katalog oder einer Fiori Gruppe. Ein Erklärung zu der Funktion ist hier beschrieben.

/UI2/PAGE_CACHE_SYNCHRONIZE

Der Report bereinigt Cache Probleme im Bereich der Launchpad Catalogs/Groups. Laut SAP sollte der Report regelmäßig eingeplant werden. Der Report ist auch über die Transaktion /UI2/SYNC_PBC erreichbar.

/UI2/EAM_BUILD_CACHE

Hier geht es um die Performance im Bereich App Finder. Weiter Informationen zu dem Report können hier entnommen werden:

Sonstiges

Änderungen an Service-Definitionen müssen manchmal manuell in Transportaufträgen aufgenommen und transportiert werden.

Fazit

Es vergeht fast kein Transport wo nicht irgendein Cache ein Problem bereitet. Aber mit dem /UI5/APP_INDEX_CALCULATE bekommt man das meist in den Griff.

Ich werden diesen Blogpost nach und nach um weitere Erkenntnisse in dem Zusammenhang ergänzen.

Jetzt vernetzen!

How to send emails from ABAP® with CL_BCS

Veröffentlicht am  von

Usage of the class CL_BCS in order to send eMails from ABAP™ applications via the Business Communication Service.

With our development tips we address special, related to praxis topics around the exciting and inexhaustible topic software development.

Valid for: SAP NetWeaver ABAP Web AS from 6.10

Index

  • General
  • e-mail dispatch from SAP
  • Class CL_BCS
  • Method CREATE_PERSISTENT – compile of a sending task
  • Method SET_DOCUMENT – attach text, data files and other objects
  • Method ADD_ATTACHMENT of the class CL_DOCUMENT_BCS
  • Method ADD_RECIPIENT – transfer of receiver
  • Method SEND – Sending of e-mail
  • Cases of application
  • Copyright & disclaimer

General

Often it is important to have necessary information at disposal in order to react quickly and in the right way. Especially, when the information procurement, like a report, takes a long time and cannot be constantly watched, it is useful to release an action upon completion. That can for example be an eMail with the status of a batch job or even the ABAP list.

eMail dispatch from SAP

SAP provided with the web AS 6.10 (6.20) the Business Communication Services (BCS) to send objects from ABAP applications. This object orientated interface is the successor of the Business Communication Interface (BCI), which is implemented as objects of the Business Object Repository (BOR).

In this Cadaxo development tip I will give an overview of the e-mail dispatch via BCS.

Class CL_BCS

Via BCS different objects with attachments and notes for several receivers can be sent also in different communication ways. Consequently the interface – the class CL_BCS – is constructed complex. In this development tip we therefore concentrate on sending an e-mail with attachment only.

A sending process breaks down into the following steps:

  • Generation of a sending task
  • Attaching an object
  • Choice of receivers
  • Sending of the mail

For all those tasks the class CL_BCA provides the following methods:

  • CREATE_PERSISTENT Compilation of a sending task
  • SET_DOCUMENT Attaching a text, data or other objects
  • ADD_RECIPIENT Add the receiver
  • SEND Sending of e-mail

Method CREATE_PERSISTENT – Compilation of a sending order

This method generates a sending task and returns an object of the class CL_BCS. All further steps are used upon that object.

Method SET_DOCUMENT – Attachment oft ext, data and other objects

With this method the content, meaning the actual text and data attachments of the e-mail is committed. The method expects an object with the interface IF_DOCUMENTS_BCS. Attachments are committed via this object too.

Via the statistic method CREATE_DOCUMENT of the class CL_DOCUMENT_BCS a respective object can be created.

The method expects the following parameters:

I_TYPE: Type of committed data, e.g. HTM für eine HTML Datei, TXT for text data, BIN for binary data like PDFs

I_TEXT/I_HEX: A chart with the actual text resp. the binary data according to the choosen type

I_SUBJECT: subject of the e-mail

Method ADD_ATTACHMENT of class CL_DOCUMENT_BCS

This method is similarly used to the CREATE_DOCUMENT:

I_ATTACHMENT_TYPE: Type of committed data, e.g. HTM for HTML data, TXT for text data, BIN for binary data like PDFs

I_ATTACHMENT_TEXT/

I_ATTACHMENT_HEX: An internal table with the actuall text resp. the binary data according to the choosen type

I_ATTACHMENT_SUBJECT: Name of the attachment file

Method ADD_RECIPIENT – Transfer of receiver

Depending on the way of communication and type of the sent object different receivers can be transferred to the mail. E.g. no business object relation can be per e-mail.

The method expect at least one object which implements the interface IF_RECIPIENT_BCS:

I_RECIPIENT: receiver address (Interface IF_RECIPIENT_BCS)

I_EXPRESS: Express message; if the receiver is a SAP user, a pop-up appears at the next processing of the PBO event with the notice of a new message

I_COPY: The receiver receives the message as a copy

I_BLIND_COPY: The receiver receives the message as a blind copy

I_NO_FORWARD: no forwarding; if the receiver is a SAP user, he cannot forward the message

The two most important receiver types are probably e-mail addresses and SAP users. The respective objects are generated by the following statistic methods:

CL_SAPUSER_BCS=>CREATE For SAP users

CL_CAM_ADDRESS_BCS=>CREATE_INTERNET_ADDRESS For e-mail addresses

Method SEND – Sending of an e-mail

The message is passed on to SAPconnect and sent via the respective interface. The actual sending process is usually scheduled by a batch job with the report RSCONN01, which periodically sends all upcoming messages. In order to avoid the waiting perioduntil the next job performance, the message can be tagged as “to be sent immediately”: Method SET_SEND_IMMEDIATELY( abap_true ) of the sending task.

Method SHORT_MESSAGE

With this method the SAPOffice dialogue opens itself for new messages, on which the user can maintain receivers, texts, attachments and their settings himself. Via parameters suggestion values for the respective fields and objects, e.g. receiver addresses, can be taken with at the time of selection, which later will be displayed in the message.