ALM Coffee Party VII – ChaRM, FB Defect Correction: The dazzling Focused Build Defect Correction (S1TM)

“Humans are creatures of habit“

Gustav Freytag already knew. When we get up, we always expect to find our slippers in the same place next to the bed, which we want to put on without looking. The consternation is great when the foot suddenly starts to flail around in the empty space. First annoyed, then panicking, we search barefoot for the slippers to finally discover the reason for their disappearance: The dog has kidnapped them and is now nibbling on them with relish.

This is a blog, not a documentation!

And this is exactly what happens again and again with the Focused Build “Defect Correction” (DC) S1TM. Suddenly, the usual actions have disappeared. In a panic, the developer runs barefoot, so to speak, to the Focused Build and ChaRM expert and asks reproachfully what has broken again, why can’t the Defect Correction be set to “Successfully tested” as before, why are they being hindered in their work?

But in reality, the lack of the actions is not a bug, but a feature. This behavior is even documented.

Well, every time a developer reads documentation, a tree is saved in the Amazon – you can guess the frequency of this arcana here:

Ibama from Brasil, CC BY 2.0, via Wikimedia Commons

As this panic scene happens quite often, I would like to use this blog to help clarify the situation. As a blog is not a documentation, it will also be read by developers! Right?

One-act play “Testing is not always the same as testing”

For the sake of simplicity, we show the diagram of a waterfall project. While the release is in the “Prepare” phase, testing takes place at work package (WP) level in the consolidation system (QA). These are the Single Functional Tests (SFT – according to the Focused Build Methodology, the developers themselves test the desired functionality) and the Acceptance Tests (AT).

When Release Management flips the big switch (Handover to release), the entire release is moved on to the pre-production system. This is where the major integration and regression tests (FIT and RT) are carried out by business users. The aim is to prove to the business that the next release is consistent and correct in itself and that the release does not break any existing functionality.

Scene I: Business as usual

The project is in the lengthy implementation phase, the release has been in “Prepare” status for months and the development team is working intensively on implementing the requirements.

The work items (WI) of a work package have been tested individually and found to be correct. Now the work package itself is tested (Single Functional Test, Acceptance Test).

The work packages are tested in the QA system. If you now find an error that requires correction, you can no longer add another transport to the WI, as the WI no longer returns from the “Successfully Tested” status.

No, you have to create a Defect Correction (DC) from the WP in order to receive a transport for the correction. The WP then switches to the “In Repair” status.

For months, it has been possible to decide within the DC whether the error has been rectified or whether it is still present by routinely selecting the corresponding action from the “Action” button.

If the correction is confirmed, the WP automatically returns to the “To Be Tested” status – hopefully for the last time.

Scene II: Oops, where are my slipp… – uh – actions?

The release finally reaches the important milestone of the end of development and Release Management sets the release to “Test” status. Test management steps into the limelight and starts the prepared test plans, whose test packages are processed by the assigned business experts, key users and testers.

If they discover a defect, they must create a Focused Build Defect (S1DM) directly from the test step. If the development team decides during the processing of the defect that a correction is necessary to rectify the error, it creates the familiar defect correction from the defect, which offers new and modifiable transports for the corrections as before.

When the defect correction is ready for testing, the hand automatically moves to the “Action” button to execute the test decision, but – scaring shock! – the “Action” button is suddenly empty! Defect Correction suddenly gives us the cold shoulder, even though the status is the same as always.

If we had read the documentation referenced at the beginning (but real developers don’t read documentation!), we would know, after a bit of scrolling, that:

This means that the tester does not have to confirm the defect correction, but the upstream defect, as this is the only way to automatically release the defect correction from its “Transport to Retesting” status.

This deviating behavior of the Defect Correction S1TM, if it was generated from a test step via a defect, must be part of the training at the start of the test phase. This avoids unnecessary agitation.

Backstage

Since this is a technical blog, I want to briefly show where this dazzling behavior of defect correction comes from.

PPF action with conditions

Status changes are carried out in ChaRM (and Focused Build is a ChaRM with bells and whistles) using PPF actions (Post Processing Framework).

Let’s take a look at transaction CRMC_ACTION_DEF “Define action profile” to see one of the two actions that are offered when testing a DC, for example the PPF action “Confirm Defect Correction with Transport”:

This action sets the status S1TMHEAD E0012 “Confirmed” when executed:

However, it is not enough for a PPF action to be defined, it must also be scheduled, otherwise it cannot be executed and will not be offered in the “Action” menu.

Scheduling is set up with the very slow and cumbersome transaction CRMC_ACTION_CONF “Configure action profile”.

This scheduling is usually linked to a scheduling condition:

Only when the condition is met does the action appear in the “Action” menu so that the user can select and execute it.

This is what the scheduling condition looks like in the somewhat funny rule editor:

The action “Confirm Defect Correction with Transport” is only offered if the current status is S1TMHEAD E0004 “Transport to Retesting” (++ is a wildcard), the process is error-free and (!) the DOCUMENT_ASSIGNED parameter is not set! CONFIRM_ALLOWED is an additional conditional parameter.

Most of the parameters in this parameter container that are evaluated in this condition originate from the currently active “Business Object”, in this case BUS2000116 “Service”. They can be recognized by the prefix “&CRM Service Process.”. These are filled automatically at runtime.

By the way, the “S” that automatically precedes the short description of the transport requests generated by the ChaRM/FB originates from this “Service”.

Further custom parameters can be defined, but you have to fill them in yourself using your own coding.

The technology behind the conditions

This filling of your own additional parameters takes place in an implementation of the Business Add-In (BAdI) CONTAINER_PPF. Transaction SE18 is responsible for maintaining BAdIs.

Here is the crucial implementation of Focused Build (SE18 -> Implementation menu -> Overview):

We are now entering the innermost part of the machine, namely the FB implementation:

The procedure is quite linear.

If a certain parameter exists in the container that is evaluated by the scheduling condition, the corresponding method is called, which is kindly called the same and which determines the value of the parameter.

• DOCUMENT_ASSIGNED() reads the direct relationship to a preceding document, and if a Defect S1DM is linked to the current process, ‘X‘ is entered as the value.
  This means that the scheduling condition is not fulfilled. The action is therefore not offered. In other words: if the defect correction is a follow-up document of a defect, it cannot be confirmed directly.
• CONFIRM_ALLOWED() closes a gap.
  It goes backwards through the document flow chain recursively, and if a defect S1DM is found here, a blank is set, which means that the scheduling condition is not offered.
  It is therefore not possible to cheat by switching another process type between the defect and the defect correction.
  However, I wonder whether the automatic function still works, namely that the confirmation of the defect also confirms the defect correction. I consider this case to be extremely rare and have therefore not tried it out.

Epilogue

I hope I have shed enough light on the dazzling behavior of the Focused Build Defect Correction S1TM to clear up the confusion.

Thanks for reading.