I had to load a static ZIP file into an HDI container table for downstream processing. These ZIP files contain industry best practices that are consumed by a downstream system to apply standardized configurations. The challenge? Getting those ZIPs into the HDI container in a way that works with .hdbtabledata.
This seemingly simple requirement comes with some surprising limitations:
We developed an automated, script-based approach:
A shell script to convert ZIP files into Base64 strings.
A CSV file that holds metadata like ID, NAME, SKU_ID, and the encoded ZIP content.
A .hdbtabledata configuration to decode Base64 into binary and store it in a BLOB column.
The .hdbtabledata mechanism used for importing data into HDI containers expects text-based formats like CSV. However:
ZIP files are binary and contain null bytes or special characters that break CSV formatting.
Base64 encoding transforms binary content into a safe, ASCII string, suitable for CSV and text-based tools.
Later, we decode the Base64 string during the HDI import to restore the original ZIP binary into a BLOB column.
CREATE COLUMN TABLE "MY_CONTAINER"."ZIP_STORE" (
"ID" NVARCHAR(50),
"NAME" NVARCHAR(255),
"FILE" BLOB,
"SKU_ID" NVARCHAR(50)
);| ID | NAME | SKU_ID | ZIP_FILE |
| b504b47a-50b6-4a16-8e5b-471cc88b6a6a | BASE_TEMPLATE_8007883 | 8007883 | ZIP_BP_20250609.zip |
| 99ded8ca-c59f-4103-b933-9049e9568185 | BEST_PRACTICE_8007885 | 8007885 | ZIP_BP_20250609.zip |
#!/bin/bash
# Input: list of entries (ID, logical NAME, SKU_ID, ZIP_FILE)
INPUT_LIST="file_list.csv"
# Output: final CSV for .hdbtabledata
OUTPUT_CSV="BASE_TEMPLATE_DATA.csv"
# Start output CSV with header
echo "ID,NAME,FILE,SKU_ID" > "$OUTPUT_CSV"
# Loop through file list
tail -n +2 "$INPUT_LIST" | while IFS=',' read -r ID NAME SKU_ID ZIP_FILE; do
ID=$(echo "$ID" | tr -d '\r')
NAME=$(echo "$NAME" | tr -d '\r')
SKU_ID=$(echo "$SKU_ID" | tr -d '\r')
ZIP_FILE=$(echo "$ZIP_FILE" | tr -d '\r')
# Check file exists
if [[ ! -f "$ZIP_FILE" ]]; then
echo "File not found: $ZIP_FILE"
exit 1
fi
# Encode zip file
BASE64_CONTENT=$(base64 < "$ZIP_FILE" | tr -d '\n')
echo "$ID,$NAME,\"$BASE64_CONTENT\",$SKU_ID" >> "$OUTPUT_CSV"
done
echo "Final CSV created: $OUTPUT_CSV"| ID | NAME | FILE | SKU_ID |
| b504b47a-50b6-4a16-8e5b-471cc88b6a6a | BASE_TEMPLATE_8007883 | UEsDBBQACAgIAJ1oiFoAAAAAAAAA...... | 8007883 |
| 99ded8ca-c59f-4103-b933-9049e9568185 | BEST_PRACTICE_8007885 | UEsDBBQACAgIAJ1oiFoAAAAAAAAA...... | 8007885 |
Now that we have the Base64-encoded CSV ready, we need to update .hdbtabledata to decode the FILE column back to binary.
We converted ZIPs to Base64, but HANA expects raw binary in the BLOB column. The decodeBase64 function tells the HDI importer to convert Base64 back to binary before inserting into the table.
"FILE": {
"name": "decodeBase64",
"type": "function",
"parameters": {
"column_name": "FILE"
}
}In .hdbtabledata, this configuration says:
"name": "decodeBase64" – tells SAP to decode the Base64 string.
"type": "function" – uses built-in transformation, not static mapping.
"column_name": "FILE" – applies decoding only to this column.
{
"format_version": 1,
"imports": [
{
"target_table": "BASE_TEMPLATE",
"source_data": {
"data_type": "CSV",
"file_name": "BASE_TEMPLATE_DATA.csv",
"has_header": true,
"type_config": {
"delimiter": ","
}
},
"import_settings": {
"import_columns": [
"ID",
"NAME",
"FILE",
"SKU_ID"
],
"include_filter": []
},
"column_mappings": {
"ID": "ID",
"NAME": "NAME",
"FILE": {
"name": "decodeBase64",
"type": "function",
"parameters": {
"column_name": "FILE"
}
},
"SKU_ID": "SKU_ID"
}
}
]
}
This approach provides a clean and reproducible way to store binary ZIP content inside SAP HANA HDI containers using only CSV and shell scripting — no manual intervention or external file handling required at import time.
By converting binary ZIPs to Base64 and decoding them during the .hdbtabledata import, we work around the limitation of HDI containers not supporting direct file system access or native binary uploads.
This method is especially useful when:
You want to automate bulk loading of template ZIPs or configuration files.
You’re building dev/test environments and want reproducible data setups.
You need to version and transport BLOB content as part of your HDI artifacts.
Hopefully, this saves you the hours I spent figuring it out. If you face additional challenges or optimize this further — feel free to share back!
Happy to answer questions or collaborate if you’re doing something similar.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
| User | Count |
|---|---|
| 46 | |
| 41 | |
| 38 | |
| 36 | |
| 30 | |
| 28 | |
| 27 | |
| 24 | |
| 24 | |
| 23 |