Homelab, Linux, JS & ABAP (~˘▾˘)~
 

Tag: file

CAP

[CAP] Display file content from external resource in Fiori Elements app via an Association

 , , , , , , , ,

I was having a situation, where I needed to access file content via an association. This led to two problems, one in the backend and one in the frontend.

My data-model.cds looked like this. 

entity MainEntity: cuid, managed {
    file            : Association to Files @mandatory  @assert.target;
}

entity Files : cuid, managed {
    content         : LargeBinary @stream  @Core.MediaType: mediaType  @Core.ContentDisposition.Filename: fileName  @Core.ContentDisposition.Type: 'inline'; 
    mediaType       : String      @Core.IsMediaType: true;
    fileName        : String      @mandatory;
    size            : Integer;
}

The file content is actually stored in an external system and is only read when the content is explicitly requested, with a call like this:

### Get file content
GET http://localhost:4004/odata/v4/admin/Files({{ID}})/content
Authorization: Basic user:password

For this kind of scenario, I have found the perfect sample code here: https://github.com/SAP-samples/cloud-cap-samples/blob/main/media/srv/media-service.js
But in my case, I needed to call the file content via an association like this:

### Get file content via association
GET http://localhost:4004/odata/v4/admin/MainEntity({{ID}})/file/content
Authorization: Basic user:password

This did not work, because in this case, we don’t get the required file ID in the Files handler in req.data.ID (find the reason here), which is needed to read the file from the external system. Therefore, I had to implement the following workaround (line 5-8), which checks from which entity we are coming and is fetching the requested file ID from the DB.

    srv.on('READ', Files, async (req, next) => {
        //if file content is requested, return only file as stream
        if (req.context.req.url.includes('content')) {

            // workaround: when File is requested via Association from MainEntity, as the ID is then not provided directly
            if (req.context.req.url.includes('MainEntity')) {
                req.data.ID = await SELECT.one.from(req.subject).columns('ID')
            }

            const file = await SELECT.from(Files, req.data.ID)
            if (!file) return next() // if file not found, just handover to default handler to get 404 response

            try {
                const stream = await getMyStreamFromExternalSystem(req)
                return [{ value: stream }]
            } catch (err) {
                req.error(`Could not read file content`)
            }

        } else return next() // else delegate to next/default handlers without file content
    })

This way, the file content can now be read directly via File and also via MainEntity following the association.

The next challenge was to display this file content in a Fiori Elements app. This works out of the box, if the file content is called directly from the Files entity, means not over an association. But if the file content is coming via an association, it seems like the Fiori Elements framework is creating an incorrect backend call. It tries to call the mediaType from the MainEntity instead of the Files entity, resulting in a failing odata call, which looks like this
/odata/v4/service/MainEntity(key)/mediaType
instead of
/odata/v4/service/MainEntity(key)/file/mediaType.
The only workaround I found was to overwrite the @Core.MediaType annotation coming from the Files entity by setting the mediaType to a hard value in the annotation.yaml of the Fiori Elements App.

annotate service.fileservice@(
    UI.FieldGroup #FileGroup      : {
        $Type: 'UI.FieldGroupType',
        Data : [
            {
                $Type: 'UI.DataField',
                label: 'Main ID',
                Value: ID,
            },
            {
                $Type: 'UI.DataField',
                label: 'File ID',
                Value: file.ID,
            },
            {
                $Type: 'UI.DataField',
                Value: file.content,
            },
            {
                $Type: 'UI.DataField',
                Value: file.mediaType,
            },
            {
                $Type: 'UI.DataField',
                Value: file.fileName,
            },
            {
                $Type: 'UI.DataField',
                Value: file.size,
            },
        ],
    },
    UI.Facets                     : [
        {
            $Type : 'UI.ReferenceFacet',
            ID    : 'GeneratedFacet2',
            Label : 'File Information',
            Target: '@UI.FieldGroup#FileGroup',
        },
    ],
);

// Workaround as currently display file content via an association in Fiori Elements is incorrectly trying to fetch the media type.
// Therefore add a fix value for the media type. Of course, this only works, if you only expect a specific file type.
annotate service.Files with {
  @Core.MediaType : 'application/pdf'
  content
};

In the Fiori Elements App it will now be displayed like this and by clicking on the Context, it will successfully load the file from the backend:

JavaScript / nodejs

[JavaScript] Download base64 encoded file within a browser

 , , , , , , , , , 
            const sBase64 = "JVBERi0xLjQKJcOkw7zDtsOfCjIgMCBvYmoKPDwvTGVuZ3....."
            const arrayBuffer = new Uint8Array([...window.atob(sBase64)].map(char => char.charCodeAt(0)))
            const fileLink = document.createElement('a')

            fileLink.href = window.URL.createObjectURL(new Blob([arrayBuffer]))
            fileLink.setAttribute('download', "example.pdf")
            document.body.appendChild(fileLink)
            fileLink.click()

Or use the npm package FileSaver.

import { saveAs } from "file-saver";

const sBase64 = "JVBERi0xLjQKJcOkw7zDtsOfCjIgMCBvYmoKPDwvTGVuZ3....."
const buffer = Buffer.from(sBase64, "base64") //Buffer is only available when using nodejs
saveAs(new Blob([buffer]), "example.pdf")
JavaScript / nodejs

[nodejs] read and write a file

 , , , , ,

https://nodejs.dev/learn/reading-files-with-nodejs

https://nodejs.dev/learn/writing-files-with-nodejs

        const fs = require("fs")

        try {
            // read from local folder
            const localPDF = fs.readFileSync('PDFs/myFile.pdf')

            //write back to local folder
            fs.writeFileSync('PDFs/writtenBack.pdf', localPDF )

        } catch (err) {
            console.error(err)
        }

Converting to Base64

        try {
            // read from local folder
            const localPDF = fs.readFileSync('PDFs/myFile.pdf')
            const localBase64 = localPDF.toString('base64')

            //write back to local folder
            fs.writeFileSync(`PDFs/writtenBack.pdf`, localBase64, {encoding: 'base64'})

        } catch (err) {
            console.error(err)
        }

Reading and writing using streams with pipe

        //read and write local file
        const reader = fs.createReadStream("PDFs/myFile.pdf")
        const writer = fs.createWriteStream('PDFs/writtenBack.pdf');
        reader.pipe(writer)

Terminal

[Shell] User and Group management & File permissions

 , , , ,
  • User and Group management
    • id
    • useradd
      • -c – Full name
      • -e – Expiration date
      • -s – Default shell
      • -d – Home directory
    • passwd
    • usermod
      • -l – rename
      • -L – Lock
      • -U – unlock
    • userdel
      • -r – remove user data
    • groupadd
    • groupmod
    • gpasswd [-a -d -A] [user1, user2] [group]
    • newgrp [group]
  • su vs. su – vs. sudo
    • visudo
  • File permissions
    • UGO – User, Group, Other
    • RWX – Read, Write, Execute
    • chmod -R g+x (grant recursive execute permission to group)
      • r = 4
      • w = 2
      • x = 1
      • – = 0
      • rwxrwxrwx = 777
      • rw-rw-rw- = 666
      • rwxrwxr–- = 774
      • rw-rw—- = 660
      • rw-r—–- = 640
    • chown
    • chgrp
    • umask

https://www.sluug.org/resources/presentations/2020/2020-02-12_permissions.pdf