Impacts of Append Structures

[former_member553956]

I'm going to append VBAP table(only 2 fields - No VARC, LCHR or LRAW datatypes) and would like to know the possible issues as per your experience when we transport the changes to the live system.

1) Can append structure cause problem to existing SAP transactions/BW extracts?
2) When transporting the change to production, we cant lock the users. So they may work on sales order related transactions when I import the transport request(TR) to the live system. Will it cause any issues?

3) When the TR(transport request) import to live system, does it cause any performance issue within the first few hours/days?
4) Pls share your experience

(otherwise, it'll end up with a P1 incident 🙂 )

[michael_piesche]

Appending a database table with an append structure is a common technique to add attributes to an existing transparent table. It is most commonly used, when someone who is not the owner/developer of the table (e.g. the SAP customer), wants to add attributes to the table to enhance functionality, without modification, so it is protected from being overwritten during an upgrade. Also SAP uses in various instances the Append Structure techniques to enhance database tables, instead of 'modifiying' the table.

• https://help.sap.com/doc/abapdocu_754_index_htm/7.54/en-US/abenddic_append_structures.htm

>> 1) Can append structure cause problem to existing SAP transactions/BW extracts?

Using an append structure to a database table is in general a safe technique, that shouldnt lead to any problems.

However, any change to coding or databases can always cause problems. Coding that will be used and coding that will access database tables should be testet thoroughly, before going live. This way, one will deal with those problems in development, test and quality systems, rather than in the productive system.

For example, all of the following can be impacted by an append structure:

• depending on how the data is fetched from the database table (e.g. by 'select *' or by selected fields)
• what structure/table is used to receive the data
• whether it is inserted/appended directly into or into corresponding fields
• and espacially how it is copied/moved/mapped to other data structures after the select

There might be some (extended) syntax checks that will give warnings or even error messages, and could draw your attention to certain hot spots. But with a standard table like VBAP, I assume you will get lots of warnings and errors with an extended syntax check, because SAP developers dont code by the rules all the time either, or the rules have been changed/added later.

>> 2) When transporting the change to production, we cant lock the users. So they may work on sales order related transactions when I import the transport request(TR) to the live system. Will it cause any issues?

I would recommend to transport this during a maintenance window. Or at least give the users a heads up that they should save their current work before the actual transport.

Otherwise, whenever there is an activation of coding or DDIC elements, a new version is created, which will in many instances cause a conflict for already running programs that are using these codings or DDIC elements.

So dumps will occur for e.g.:

• Users, who will loose their current session and the work they have been doing.
• Programs, running in the background, will be terminated.
• Depending on how the coding and DDIC elements are cashed by the running program, this can happen right at the point of transportation/activation, but also hours later, when a user for example returned from lunch and the user session was still active.

In case of database table activations, which are also activated with an append structure, the dump will definitly occur when the program is already running while the activation takes place and a database access is performed after the activation.

>> 3) When the TR(transport request) import to live system, does it cause any performance issue within the first few hours/days?

If you append a structure with attributes that all can be NULL (Flag for "Initial Values" is left blank, otherwise those fields have to be initialised to there ABAP initial value for all records), and you dont create a new secondary index for your new fields or other VBAP fields, then the activation in production shouldnt be much longer than in the other dev, test and quality systems. It will definitly take longer than activating a simple standalone ZTABLE, because VBAP is referenced many times and cross-checks will take place. In my sandbox system it took already 1 minute to activate VBAP fully. So take note of the activation time in each system, in case it takes more time with more data.

But if your programs accessing those newly appended fields and they rely on also inital values (e.g. a flag where X = true and initial = false), and you want those fields to have the correct initial value from the start, you will have to activate the "Initial Values" flag. But keep in mind, that this can take a while during activation depending on the amount of records of your table, because, all records of the table VBAP will have to be loaded by the DB and the initial values will have to be set. If it is left as NULL values, the activation is faster, but e.g. a SQL select like "WHERE newfield = space", will not lead to any hits, as long as there hasnt been an update (explicit update for the specific fields or implicit for all fields of the record).

>> 4) Pls share your experience

Have appended e.g. structure CCDATA in the past with namespace append in several customer systems, which led to appends for numerous other structures but also for database tables FPLTC and BSEGC. Testing and Golive went rather smooth.

When you append one standard structure or table, you might have to append others as well, in order to get the data from one table to others as well. With VBAP there are many other structures for sales order creation through Idoc, and also for moving data to VBRP. So depending on your requirements, you might not be done with 'just' appending VBAP.

[Sandra_Rossi]

4) Pls share your experience

Then I hope the OP will share his own experience... 😉

[former_member1716]

praveenw77,

Adding fields via Include structure is safest way to add fields. Ensure you do the following checks once its added:

1) Ensure proper data types are maintained and added at appropriate place.

2) While adding the fields ensure the Initial Check box is checked else values for those fields for existing entries will be NULL.

3) Post activating the structure and the table also ensure the table is activated via SE14.

4) Ensure all the relevant changes are captured in Single TR.

5) Move the changes only during Non-business hours or maintenance window.

6) Post adding the fields test the system by adding new entries to the table.

7) Also check on the existing entries as well.

Regards!

[former_member309012]

Hello Satish/Michael,

When creating an APPEND-structure, the option to initialize the new field(s) cannot be selected/ticked.

See how it looks like in SE11 (attached).

Modifying the base table and adding fields there obviously enables the option to initialize. But how to do the same when the table actually gets an appended structure? I must miss the obvious.se11-01.jpgse11-02.jpg

Thank you in advance! / Ulrich

[Sandra_Rossi]

Satish and Michael may not have subscribed to the question and so won't be informed of your question, so you should better copy/paste their hyperlinked name if you want to more certain that they see it.

Note that you can show the images inside your question instead of just hyperlinking them (otherwise it requires many clicks to read your question).

[former_member309012]

Hi michael.piesche satishkumarbalasubramanian

In case you have a minute ... 🙂

Thank you in advance, / Ulrich