In this How to guide, I will take you through the steps required to Apply patches in SAP Service and Asset Manager metadata definitions.
Contents:
What is a patch?
Why the fix is provided as a patch?
How to apply the patch?
Appendix
What is a patch?
A patch is a compact representation of the differences between two files, intended for use with line-oriented text files. It describes how to turn one file into another, and is asymmetric: the patch from file1 to file2 is not the same as the patch for the other direction.
Why the fix is provided as a patch?
Earlier, the fixes were provided as files including the change(s). The user has to replace the original standard file(s) with patch file(s) to get the fix.
It was a challenging and manual activity when 2 separate fixes required changes in the same file. To address this, a patch format was introduced for metadata fixes. The patch format uses context and line numbers to locate differing file regions. It can be applied to a somewhat earlier or later version of the first file than the one from which it was derived, as long as the applying program can still locate the context of the change.
A single patch file can contain the differences for any number of files, and git diff produces diffs for all altered files in the repository in a single patch.
How to apply the patch?
Patch can be applied in below IDE
Option 1: Offline - Microsoft Visual Studio Code
Let’s use example of SAP Note 3486946 for 2405 metadata.
1 a) Download metadata patch file from SAP Note 3486946.
Download 3486946(2405).patch file from https://me.sap.com/notes/3486946
1 b) Copy patch file in Microsoft Visual Studio Code.
Copy the downloaded file preferably adjacent to metadata definitions folder
1 c) Apply patch to SAP Service and Asset Manager metadata.
Open embedded terminal in Microsoft visual studio code(Menu>Terminal>New Terminal), navigate to metadata definitions folder and run patch command.
patch --no-backup-if-mismatch -p4 < ../3486946\(2405\).patch
The --no-backup-if-mismatch option causes patch to not create backup files, even for mismatched patches
-p<n>
Remove <n> leading path components (separated by slashes) from traditional diff paths. Example with -p2, a patch against a/dir/file will be applied directly to file.
-p4 means, it is going to remove 4 leading path components
From a/src/metadata/definitions/Application.app to Application.app
patching file Application.app indicates the changes has been applied successfully.
Option 2: Online - SAP Business Application Studio
2 a) Download metadata patch file from SAP Note 3486946.
Download 3486946(2405).patch file from https://me.sap.com/notes/3486946
2 b) Copy patch file in SAP Business Application Studio.
Upload the downloaded patch file preferably into metadata definitions folder
2 c) Apply patch to SAP Service and Asset Manager metadata.
Open embedded terminal (Menu > View > Terminal)
Run patch command from metadata definitions folder
patch --no-backup-if-mismatch -p4 < ./3486946\(2405\).patch
patching file Application.app indicates the changes has been applied successfully.
Note: Delete 3486946(2405).patch file from the project structure after applying the patch.
Appendix:
Possible reasons for patch command failure
Common:
1. You have to be in the correct-level directory matching -p<n> option.
-p<n> removes <n> leading path components (separated by slashes) from traditional diff paths. Example, with -p2, a patch against a/dir/file will be applied directly to file.
2. The file has to exist in your project structure that you’re trying to patch
3. Partially applied – If patch has been applied to 2 out of 3 files. Follow Point # 4, revert changes for first 2 files and then reapply.
Important:
4. The file has to be “sufficiently similar” to the one from which the patch was produced, otherwise the patch will fail to apply. - Make sure patch context is honoured. Apply patch on standard metadata. In case of customization, open the .patch in text editor and make changes manually. Refer “What is the structure of a patch” section.
5. Point #4 applies to all files in the .patch
Others:
What is the structure of a patch?
Here is a simple patch from SAP Note 3486946 - SAP Service and Asset Manager - App update failed, NativeClass is not defined
3486946(2405).patch
diff --git a/src/metadata/definitions/Application.app b/src/metadata/definitions/Application.app
index 27681dc0d5..e7e901ddcc 100644
--- a/src/metadata/definitions/Application.app
+++ b/src/metadata/definitions/Application.app
@@ -22,5 +22,5 @@
"OnSuspend": "/SAPAssetManager/Rules/ApplicationEvents/ResetPeriodicAutoSync.js",
"OnExit": "/SAPAssetManager/Rules/ApplicationEvents/ExitEventHandler.js",
"OnLinkDataReceived": "/SAPAssetManager/Rules/DeepLinks/LinkDataReceived.js",
- "_SchemaVersion": "23.4"
+ "_SchemaVersion": "24.4"
}
Breaking this into sections:
diff --git a/src/metadata/definitions/Application.app b/src/metadata/definitions/Application.app
This is the Git diff header. diff --git is not a literal command, but rather just suggests the notion of a Git-specific diff in Unix command style.
a/src/metadata/definitions/Application.app and b/src/metadata/definitions/Application.app are the files being compared, with added leading directory names a and b to distinguish them in case they are the same (as they are here, this patch shows the changes from one version to another of the same file). To generate this patch, I changed the file Application.app and ran git diff, which shows the un-staged changes between the working tree and the index. There are no directories named a and b in the repository, they are just conventions.
index 27681dc0d5..e7e901ddcc 100644
This is an extended header line, one of several possible forms, and only one in this patch. This line gives information from the Git index regarding this file: 27681dc0d5 and e7e901ddcc are the blob IDs of the A and B versions of the file contents being compared, and 100644 are the mode bits, indicating that this is a regular file: not executable and not a symbolic link (the use of .. here between the blob IDs is just as a separator and has nothing to do with its use in naming). Other header lines might indicate the old and new modes if that had changed, old and new filenames if the file was being renamed, etc.
The blob IDs are used if this patch is later applied by Git to the same project and there are conflicts while applying it. If those blobs are in the object database, then Git can use them to perform a three-way merge with those two versions and the working copy, to help you resolve the conflicts. The patch still makes sense to other tools besides Git; they will ignore this line.
--- a/src/metadata/definitions/Application.app
+++ b/src/metadata/definitions/Application.app
This is the traditional unified diff header, again showing the files being compared and the direction of the changes, which will be shown later: minus signs will show lines in the A version but missing from the B version; plus signs, lines missing in A but present in B. If the patch were of this file being added or deleted in its entirety, one of these would be /dev/null to signal that.
@@ -22,5 +22,5 @@
"OnSuspend": "/SAPAssetManager/Rules/ApplicationEvents/ResetPeriodicAutoSync.js",
"OnExit": "/SAPAssetManager/Rules/ApplicationEvents/ExitEventHandler.js",
"OnLinkDataReceived": "/SAPAssetManager/Rules/DeepLinks/LinkDataReceived.js",
- "_SchemaVersion": "23.4"
+ "_SchemaVersion": "24.4"
}
This is a difference section, or hunk, of which there is just one in this diff. The line beginning with @@ indicates by line number and length the positions of this hunk in the A and B versions; here, the hunk starts at line 22 and extends for 5 lines in both versions. The subsequent lines beginning with a space are context: they appear as shown in both versions of the file. The lines beginning with minus plus signs have the meanings just mentioned above. This patch replaces a single line, fixing a schema version whereby the app update would fail mentioning NativeClass is not defined.
Patch Context:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
6 | |
5 | |
5 | |
5 | |
5 | |
5 | |
3 | |
2 | |
2 | |
2 |