Spammy Messages on Exception classes

I need a smarter ABAP developer to tell me this. Why does it take 10 steps to link a t100 message to a particular instance of an exception class? For every message text, you have to define the exception variables within the exception class, then create the exception text, then create a t100 message, then link the message and each message variable( this is the painful step), then raise the bloody exception class with exporting parameters specific to that message. It's a pain. Alright to all you lucky guys on ECC7 and ECC8, have they made this easier? SAP, At least put a table control grid to so I can link the t100 message variables easier. My clients won't understand why I took 3 days just to create messages the "right way". I've given up and decided to raise "message into lv_dummy", raise exception class and reevaluate the sy variables using a static method from a crossapp utility class. I cut-paste it everywhere...job done.


- Posted using BlogPress from my iPhone

Story of a Landscape change and Transports for a major release

I’m going to recount a recent experience with transports and a landscape change. I’m reasonably happy to be still learning.

Background
We started a new integration project and due to the large number of developments, decided to deploy the project's development environment in a separate instance. Developments and configuration are then migrated ithrough the normal “Business-as-usual(BAU)” DEV,QA and Prod as part of a change control process.

We also have Revtrack which helps somewhat in warning us of object contentions.


The first event
A significant change in landscape required us to consolidate the development in the BAU environments. It was a reasonable choice except for some issues below.

Here are some of the problems we encountered

• The transports have to be imported into the BAU environment and old transports in the project system has to be quarantined in Revtrack.
• The source system of development objects have to be changed so that they don’t get classified as repairs (This is done through SE03).
• Some of the data remained in the Project Environment which meant that in order to test, new transports have to be released. This led to a proliferation of small transports.

Because of the mass of new transports during testing, the migration to the QA environment was projected to be quite tedious. Revtrack will OOPS all over the place. I decided to create a “SuperRevtrack” to consolidate all the related developments under my area which reflects the latest state of the development environment.

Due to the SuperTransport, the migration to QA went well and integration testing started on track. It solves one problem, but creates a big one later…


The second event
During integration testing, in order to manage incremental changes, the SuperRevtrack was frozen. Changes were created in new new Revtracks.

This was done to allow different developers to migrate their changes to QAS independently.
Unfortunately, the masses of transports came back to haunt us.

Revtrack will release to Prod in the order that transports were released.
Despite this, we knew that adjustments on the data dictionary objects would kill the Supertransport and items will not activate properly on the first run.

The only way to ensure that everything activated properly was to transport them all…TWICE.

The risk
The main issue with the migration is that it contained pricing routines and pricing condition tables which had the potential to stop SD in production in its tracks if it didn’t go in properly. Further, there were also extensions to customer data, pricing and output communication structures. Warehouse interfaces to SAP using RF and .Net connector is likely to be impacted by code regeneration due to the communication structures.

As the migration was considered a high-risk move to stop production capability during daytime, the changes went in on a weekend mid-night with a full complement of support staff monitoring the change.

We acquired a special approval for a 2 hour maintenance window (the standard one was 1 hour). All the weekend background invoicing and rebate calculation jobs were stalled. We had 21 revtracks with 50+ transports and one supertransport containing 300 objects.

Luckily, it went in as planned. 1hour 45 minutes.We had 15 minutes to spare. Production did not fall over.

Later we were notified that the development environment was being maintained at the same time and it would have been potentially disastrous had the Production migration did not went in as planned.


Lessons

Here are some lessons I've learned here and in previous experiences.

• For the first release in a major wave, plan and build the transport / release pack beforehand. (objects on subsequent releases are typically less cross-dependent) .
• Data dictionary and cross app objects can be put in separated revtracks. Putting these in their own transports saves on the analysis costs for transport dependencies on programs (analysis costs are incurred for every migration stage).
• Request a separate transport for the pricing condition table definition or include it in your common data . This is typically generated by the Pricing Functional team.
• Revtrack cannot manage the migration to prod by itself. It’s a good feature that it transports to production based on release date and it’s good for small support changes. But big releases for projects generally would still require transport level analysis.
• Creating data in the development environment saves time. The functional team may not always like it – but it’ll be better for them and for support later on. It also saves on the number of transports to track.
• The whole transport path must be up and running for a major release pack.
• The Basis support for the night must have special approval to move emergency items into production if things did not go well.
• Basis folks do not like super-transports because it is often hard to determine whether it is stuck in the system or still processing.