FAQ: BI Java Support Packages/Patches
This tutorial provides answers to frequently asked questions (FAQs) with regard to the Support Package Stack and the patch strategy for BI Java.
What is BI Java?
From a technical perspective, BI Java consists of the following J2EE Software Component Archives (SCAs):
- BIBASES.SCA - BI BASE SERVICES
- BIWEBAPP.SCA - BI WEB APPLICATIONS
These two SCAs must use the same Support Package Stack (see the answer to the next question for more information about the dependencies of Support Package Stacks) and they must also be on the same patch level.
However, there are further BI components in J2EE that do not have to be on the same patch level as the SCAs mentioned above. However, they must be on the same Support Package Stack level (see the next question):
- BIIBC.SCA - BI INFORM. BROADCASTING
- BIREPPLAN.SCA - BI REPORTING AND PLANNING
- BIUDI.SCA - BI UDI
In addition, there are SCAs that, although their names begin with BI, can also be used in a broader environment (for example, without using the BI function):
- BIMMR.SCA - BI META MODEL REPOSITORY
- BIWDALV.SCA - BI WEBDYNPRO ALV
What must I bear in mind when upgrading from BI Java to a higher Support Package Stack?
By definition, a Support Package Stack in J2EE is a group of NetWeaver SCAs that all have the same Support Package Stack number. This group of SCAs is tested internally by SAP and checked for validity. Using a system where the Support Package Stacks of the SAP NetWeaver SCAs differ is generally not supported.
There are exceptions to this rule, for example, if SAP Business Packages have been implemented. These use a different numbering from the one usually used for SAP NetWeaver Support Package Stacks.
In addition, BI Java is greatly dependent on the related ABAP stack. In Document 1013369, there is a list of the permitted combinations of J2EE and ABAP Support Package Stacks. All other combinations are generally not supported.
What is a patch for BI Java?
Basically, a patch for BI Java consists of various corrections for the SCAs BIBASES.SCA and BIWEBAPP.SCA mentioned above. You can apply these patches in systems that use the same Support Package Stack level as the available patch.
Does applying a patch for BI Java overwrite the corrections from a patch that I previously applied?
No. Patches in J2EE are cumulative. This is different from an ABAP document containing an advance correction. Therefore, a patch with the same Support Package Stack version and a higher patch level contains all the corrections of the patch with the lower patch level.
When you upgrade to a higher Support Package Stack, situations may occur whereby the new Support Package Stack does not yet contain a certain correction released in a patch. Therefore, it is important to have the new Support Package Stack on the latest patch level available for BI Java.
Also, check the notes for the corrections that you implemented in your system to see whether you should postpone the upgrade because a certain important correction is not yet available for the new Support Package Stack.
Why is it important to have applied the latest patch for BI Java before reporting an error?
If a customer message is sent to SAP Development Support, the SAP developers usually set up a BW-RFC connection between the ABAP system of the customer and a J2EE installation on the computer of the developer. This local J2EE developer connection does not make any changes to the settings of the customer system but it will already have deployed the latest patch for the Support Package Stack of the customer.
If the problem cannot be reproduced with this local J2EE installation, SAP returns the message to the customer and proposes the deployment of the latest BI Java patch (see also the answer to the question "Can I receive a correction that corrects only the problem I reported and does not change anything else?"). To avoid this time-consuming process, you should check yourself whether applying the latest BI Java patch solves the problem.
If the problem is not solved by applying the latest BI Java patch, SAP development tries to provide a patch with a correction to the problem (if no patch can be provided, see the answer to the question "Why can certain problems not be solved with a patch for BI Java?"). Since patches are cumulative (see the answer to the previous question), you always receive all the corrections of the latest BI Java patch as well as all other corrections that the patch available to you contains.
Why does it take so long to provide a patch for BI Java?
Customers that report a problem that can be traced back to an error in the source code in J2EE must apply a patch to correct the problem. Since patches are cumulative (see the answer to the question "Does applying a patch for BI Java overwrite the corrections from a patch that I previously applied?"), the customer also receives all other corrections that are available for the Support Package Stack that he uses.
It is therefore important for the customer that the patches provided are of high quality since problems in patches automatically affect a large number of customers and they cannot be applied selectively as is the case with ABAP correction instructions. SAP must therefore conduct various tests before releasing the patch. These tests check whether the problems (reported as to be corrected) are really corrected in all cases. In addition, further tests must ensure that functions that work correctly are not damaged by the patch (damaging a function that works correctly is called regression.
Since SAP supports several Support Package Stacks at the same time (and recommends that you use the latest Support Package Stack), the tests must be carried out for each of these Support Package Stacks.
A lot of resources and time are taken up by these tests. Therefore, the tests must be planned in such a way that only one patch for one Support Package Stack is executed at a time Creating the binary files for the patch, deploying these files on our test systems and (after all tests have been carried out successfully) their delivery to SAP Service Marketplace contain additional, time-consuming steps.
This explains why the delivery of a patch for BI Java usually takes longer than the release of an ABAP patch with an advance correction.
Why was the planned delivery date of a patch for BI Java postponed?
Avoiding regression is the main target when delivering new patches for BI Java (for more information, see the answer to the preceding question). This means that SAP does not deliver a patch with known regression errors; SAP corrects these errors first. If a regression is found just before the delivery, this leads to another cycle of correction creation, patch production, deployment and retesting. The planned delivery of the patch for BI Java is postponed if this cycle takes too long to meet the delivery date of the patch. Check regularly the affected patch notes for your Support Package Stack to be aware of changes to the planned delivery.
Why must I test after I apply a patch for BI Java?
Even though SAP takes all possible measures to prevent the delivery of regressions, you are advised to test your scenario extensively after you apply a patch for BI Java to avoid problems in your production scenario.
Can I receive a correction that corrects only the problem I reported and does not change anything else?
This is not possible due to technical reasons. As opposed to ABAP, corrections are delivered only in binary form in Java. Therefore, the patches have to be delivered sequentially and cumulatively (for more information, see the answer to the question "Does applying a patch for BI Java overwrite the corrections from a patch that I previously applied?").
Due to this sequential, cumulative nature of the patch process, SAP retains only the latest source code version including all the corrections. Since this source code is the basis for new corrections, all new patches always contain all previous corrections.
Why can certain problems not be solved with a patch for BI Java?
To implement the function provided, the J2EE components of BI Java collaborate with ABAP and the .NET tools. Some corrections require changes to J2EE, ABAP and/or the .NET tools. Although this should not be a problem, there are certain situations in which no such corrections can be created:
To correct certain behaviour, you must implement the corrections in J2EE and ABAP and/or the .NET tools in your system. If you implement only some of the corrections, malfunctions may occur that are seen as regression by other customers that, for example, apply only the patch for BI Java. Since it is impossible to inform customers reliably of such dependencies, SAP generally does not make such corrections available as a patch in the interests of all customers.
Certain corrections in ABAP require actions that cannot be delivered using a note (for example, adding table entries). If a correction affects both BI Java and ABAP and meets the criteria of the preceding point, SAP generally does not provide such corrections.
In addition, the risk of introducing regressions and unnoticed side effects is higher with some corrections. Since the probability for unnoticed side-effects is high, the standard test procedures for patches cannot always recognize such problems. They can only be found in a Support Package Stack test, which is more extensive than a patch test. If SAP development believes that a certain correction has such a high risk, SAP generally does not provide this type of correction.
Why can certain functions that are available in a higher Support Package Stack not be ported to the lower Support Package Stack that I use?
Refer to the answers to the questions "Does applying a patch for BI Java overwrite the corrections from a patch that I previously applied?", "Why does it take so long to provide a patch for BI Java?", "What must I test after I apply a patch for BI Java?" and "Can I receive a correction that corrects only the problem I reported and does not change anything else?".
All the facts in these answers strictly forbid the subsequent transfer of certain functions to a Support Package Stack that was already delivered since this transfer with a patch poses a far greater risk than the correction of errors. SAP acts in the best interests of all customers and having a stable system is not best served by this type of transfer of functions.
Why have new patches been created only for the last three Support Package Stacks delivered?
First refer to the answers to the question "Can I receive a correction that corrects only the problem I reported and does not change anything else?". Since a patch is cumulative, corrections are delivered in a patch of an earlier Support Package that spans several Support Packages. The further back in the past a Support Package goes, the more corrections you get in a new patch for this Support Package Stack.
Starting position: Support Package Stack 10 Patch 19, Support Package Stack 11 Patch 14, Support Package Stack 12 Patch 6 available for customers and Support Package Stack 13 is in development.
Corrections can come in two ways in Support Package Stack 10 Patch 20.
1) Standard case: A customer is on Support Package Stack 10 and discovers an error. This error is now corrected as standard with Support Package Stack 10 Patch 20, Support Package Stack 11 Patch 15, Support Package Stack 12 Patch 7 and Support Package Stack 13 Patch 0.
2) Serious error: A customer is on Support Package Stack 12 Patch 6 and discovers an error. This is corrected with Support Package Stack 12 Patch 7, Support Package Stack 13 Patch 0. The developer now deems the error so serious that he brings the correction back to Support Package Stack 11 Patch 15 and Support Package Stack 10 Patch 20
Because of 2), Support Package Stack 10 Patch 20 then contains in total some corrections from three different Support Packages but not all the corrections. Refer to the answers to the question "Why can certain problems not be solved with a patch for BI Java?" for this. You can implement the missing corrections only by importing a Support Package. On the other hand, due to the missing corrections, accidental side-effects may arise in the other corrections (also during implementation), the probability of which increases the further away the patch is (due to the total of the corrections) from the original status of the Support Package Stack (taking delivery, testing, validation and so on into account).
Therefore, if you discover an error in an earlier Support Package Stack and, from the error analysis, it transpires that this, according to standard case 1), is already known and corrected for your Support Package Stack, a patch released for customers exists for the relevant Support Package Stack that corrects the error. Therefore, a patch provides the customer with a known solution (also for earlier Support Package Stacks).
However, if you have an unknown error, no patch released for customers exists for the relevant Support Package Stack that corrects the error. This error is thus a new and not yet known error. In this case, a correction can be provided in a patch with justifiable risk for at most the last three Support Package Stacks.