Copying an Internal Table into another Internal Table

You can copy one or more rows of an internal table into another internal table by using the statement INSERT LINES OF.

Note the difference between INSERT LINES OF and APPEND LINES OF:

INSERT LINES OF

Copies the contents of several rows of an internal table to another internal table.

APPEND LINES OF

Appends the contents of several rows of an internal table to another standard table.

Read more...

Introduction to SAP Business Workflow

A workflow is a model that describes a sequence of operations, representing an actual business process.

A simple example would be a leave request. An employee calls his manager saying he’d like to take a vacation. The manager asks for specific dates. The employee specifies the date in which he’ll be absent, to which the manager replies with either “I approve your request” or “Forget it.”

Using a workflow engine, the process described above can be automated. An employee would fill the details in a familiar environment (examples being it could be an SAP transaction, Outlook, SharePoint, or the SAP UWL), the manager would get an approval request in his inbox, and would then either approve or reject the request.

There are many workflow engines in the market, and SAP Business Workflow is one of them. It’s the most popular SAP workflow engine to date, allowing execution of business processes within SAP application systems. It comes with predefined workflow models, but using the modeling environment, a customer can design his own workflows, tailored for his specific business needs.

There are a lot of excellent tutorials online for those of you wishing to learn about workflows in SAP, here is some basic information:
• The main transaction allowing viewing and editing the workflow model is transaction SWDD.
• The following video contains an excellent example on how to build your first workflow model (kind of a “hello world workflow”). Note: You must have an SAP SDN account to view this video. Creating your first workflow (Video)
• Here are some official workflow tutorials from SAP help.
• And as always, SAP SDN has an excellent page about Workflow.

Read more...

Iterating On a Table Using Field Symbols

Say you have a Table called “table_name”, of line type “table_row”, and you wish to iterate on it and perhaps change the rows while you’re iterating. You can do it in ABAP using field symbols.
First, you need to define the field symbol. In our example it’s called “symbol_name”


FIELD-SYMBOLS <symbol_name> TYPE table_row.


Now, you can iterate over the table, assigning each row to the field symbol


LOOP AT table_name ASSIGNING <symbol_name>.
...
ENDLOOP


On each iteration, you can manipulate the table using the field symbol. Any change done to the field symbol is also done on the table. It’s like using a pointer in C or a reference variable in C++.

Important note: When using field symbols on sorted or hashed table, then you may not change the key fields of these tables. Doing so results in a runtime error. The logic is simple: changing the key will change the sorting order or hashing order of the table, and since you’re in mid-iteration, it may cause you to re-iterate on these rows. You Java developers out there may be familiar with this concept, as it also exists in Java.

You can read more about field symbols at the following SAP help link.

Read more...

The difference between INSERT, UPDATE, and MODIFY

Here's a very common syntactic question: What's the difference between INSERT, UPDATE, and MODIFY?
The answer is plain and simple:

INSERT - inserts a new record. INSERT expects that a record with the required key does NOT exist in the table. Therefore, if a record with the same key already exists, a runtime error occurs. For more details on INSERT, visit here.

UPDATE - update an existing record. UPDATE expects that a record with required key exists in the table. If a record with the required key does not exist, it issue an error (sy-subrc is 4). For more details on UPDATE, visit here.

MODIFY - acts like a combination of INSERT and UPDATE. If a record with the specified key does not exist, it adds it to the table. If a record with the specified key does exist, it modifies it. So MODIFY actually acts like "Insert or change record". To read more about MODIFY, visit here.

To summarize:
INSERT - adds a new record to the table. If the row (key) exists, issues an error.
UPDATE - updates an existing record to the table. If the row (key) does not exist, issues an error.
MODIFY - If the key exists, modifies the record. If the key does not exist, adds the record to the table.

Read more...

Reflection in ABAP

Say you want to create an instance of a class that implements a certain interface, but you won’t know the name of the class you want to create until runtime. In Java or .NET you would have used the reflection mechanism, but can you handle this case in ABAP?
Apparently, you can.
Here’s a short code snippet showing how:



DATA: iv_classname TYPE seoclsname.
DATA: iv_interface TYPE REF TO IF_INTERFACE_NAME.
DATA: gr_error TYPE REF TO cx_dynamic_check.
DATA: gv_message TYPE string.

iv_classname = 'CL_CLASSNAME'.

TRY .
CREATE OBJECT iv_interface TYPE (iv_classname).

CATCH cx_sy_create_object_error INTO gr_error.
gv_message = gr_error->get_text( ).
WRITE :/1 gv_message.

CATCH cx_sy_dyn_call_param_missing INTO gr_error.
gv_message = gr_error->get_text( ).
WRITE :/1 gv_message.

ENDTRY.



Let’s have a look at the code.
In the first four rows, you define several variables data types.
iv_classname hold the name of the class (that’s the name which will be known only in runtime)
iob_object – a reference to an interface that the class you’ll instantiate implements.
The other two variables are for error handling purposes.
Now, you use the CREATE OBJECT ABAP statement.


CREATE OBJECT iv_interface TYPE (iv_classname).



Note that had you known the class name during compile time, you could use the following statement:


CREATE OBJECT iv_interface TYPE CLASSNAME.


The difference? No parenthesis, plus you give the class name instead of a string containing the class name.
Let’s move on. In case the class does not exist on the system you’re running (or your provided a wrong class name), you’ll get the exception CX_SY_CREATE_OBJECT_ERROR, saying that the class you’re trying to instantiate couldn’t be found. In case there are missing parameters, you will get a CX_SY_DYN_CALL_PARAM_MISSING exception. Note that in the example above no parameters were passed to the constructor, but in case there are parameter, the creation statement should look as follows.


CREATE OBJECT iv_interface TYPE (iv_classname) EXPORTING param1 = value1 param2 = value2.


You now know a little bit about dynamically instantiating objects in your code – a great way to implement dynamic and extensible factory methods!

Read more...

Using ABAP Exception classes with Message classes (Part 2 of 2)

In the previous post, we created a simple ABAP exception class that uses a Message Class. Now let’s see how we can use this class. It’s strongly recommended that you read part one before continuing.

The statement for raising (or throwing) an exception class that uses a Message class looks as follows:

raise exception type CX_DB_ERROR
exporting TEXTID = CX_DB_ERROR=>WRITE_ERROR
TABLENAME = ‘SPFLI’.


Let’s analyze this statement. First, we state the type of the exception, which is CX_DB_ERROR (that’s the exception that we created in the previous post). Next, we’re passing the parameters to the exception.

The first parameter answers the question – “What is the message we want to display?” It states the key of the text that we want to insert. Since we want to display a text for a “database write error”, we pass the key WRITE_ERROR (Remember it from last time? We created it on step 6).

The second parameter answers the question “What are the parameters needed for the message we want to display?” If you remember, our message had one parameter, the table name, so that we could imply that the write error occurred on this or that table. So here we pass the name of the table, in this example it’s the famous SPFLI.

So far we’ve looked on how to throw the exception. Now let’s take a look at the code for catching the exception.


data OREF type ref to CX_ROOT.data TEXT type STRING.

try.

... “Some method that throws CX_DB_ERROR

catch CX_DB_ERROR into OREF.

TEXT = OREF->GET_TEXT( ).

endtry.


In this simple code example, we catch the exception CX_DB_ROOT into a variable called OREF. We then extract the exception text into the variable TEXT by using the GET_TEXT() method.

At the end of this code execution, the variable TEXT should hold the following string:

“An error occurred when writing to table SPFLI”.

Note: There is another parameter which is commonly passed when creating an exception. It is called PREVIOUS, and it’s used to wrap exception in case of an exception chain. Those of you who have experience with Java or .NET are probably familiar with this concept. To all the others, don’t worry – we’ll mention exception chains later on.

Read more...

Using ABAP Exception classes with Message classes (Part 1 of 2)

We’ve talked about Exception Classes, and we’ve talked about Message Classes. Now let’s see how we can combine these two together.

Let’s take a scenario, in which you have an exception that is thrown whenever a database error occurs in your program. Let’s call this exception class CX_DB_ERROR. We want our exception to display various messages that can also be translated later on to different languages. For example, “Error when writing to database” or “Error when reading from database”. So let’s combine ABAP Exception and Message classes.

1. First, create a message class through SE91. For this example’s sake, let’s call it CM_DATABASE_MESSAGES

2. Add a few messages to the message class. For our example, let’s add the message: “An error occurred when writing to table &1”. &1 indicates that a parameter would be inserted to the message. This parameter would be the name of the table that caused the error. We’ll get back to this in a few minutes.

3. Now open SE80 and create the exception class CX_DB_ERROR .

4. Remember that our message from step 2 states which table caused the error? Now’s the time to add this parameter. So click on the “Attributes” tab, and add an attribute for the table name. Let’s call it TABLE_NAME, and give it the type STRING.

5. Next, click on the “Texts” tab.

6. Enter a key to the message you would like to display on your exception class. In our example, let’s add the key WRITE_ERROR, indicating an error occurred when writing to the database.

7. Click on the “Message Text” button.

8. A new dialog opens, titled “Assign Attributes of an Exception Class to a Message”.

9. In the field “Message Class”, insert the name of the Message Class associated with your exception class. Let’s insert the class CM_DATABASE_MESSAGES, which we created earlier.

10. Now we need to choose the message number. Click on the choice button and choose the message “An error occurred when writing to table &1”. The number of the message should now appear in the field (as we created only one message in our example, it should be 000).

11. Now, you have to choose attributes that would be associated with the parameter &1. Click on the drop down list button, and choose the TABLE_NAME attribute we created earlier.

12. Save everything and activate.

You’ve just finished creating an exception class that uses a message class. In the next post, I’ll show you how to use the exception class with the message.

Read more...