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

[Fiori] MyInbox – Custom App reloads infinitely

I recently had the situation, that after a standalone Gateway System got patched, a custom app in the My Inbox app did not load anymore, when clicking on a workitem. When opening the network tab in the dev tools, you could see three requests send over and over again. It called the manifest.json, a batch request to the OData Service and some i18n.properties calls. You could also see the app files in the sources tab, which means that app had already loaded correctly but could not be displayed because it kept restarting for some reason.

When searching via Perplexity, I found the following post in the SCN: https://community.sap.com/t5/technology-q-a/sapui5-custom-app-navigation-from-myinbox-calls-app-in-infinite-loop/qaq-p/690650
But moving the “parent” property did not help, although the described issue sound similar.

Since everything worked before the system patch and the custom app wasn’t changed, it must have been related to an updated My Inbox app or to the new UI5 version, which affected the custom app.

When scrolling through my bookmarks, I found this note: 2305401 – Integration of SAPUI5 Fiori Applications into My Inbox 2.0
When checking the attached PDF, I found the following in chapter 4:

This “repeatedly loading” was exactly my problem! And since the Gateway got patched, I guess a new My Inbox version came with it. When checking the manifest.json in the custom app, there was no async property at all.
After adding "async": true to the mainfest.json, the custom app started to load successful again. Nice!

[SAPUI5] Create app with full screen width / full screen layout

https://experience.sap.com/fiori-design-web/full-screen/

https://stackoverflow.com/questions/55832369/how-to-disable-or-enable-letterboxing-and-adjust-ui5-for-the-widescreen/56137602

Simply add appWidthLimited:false in your index.html

		<script>
			sap.ui.getCore().attachInit(function() {
					new sap.m.Shell({
						appWidthLimited:false,
						app: new sap.ui.core.ComponentContainer({
							height : "100%",
							name : "my.demo.app"
						})
					}).placeAt("content");
				);
			});
		</script>

[SAPUI5] Replace OData Service manually in Extension Project

After redefining an OData Service like it is described here, you also have to add your new service in your Extension Project, so that the App knows, that it should use your redefined service instead of the default one. In the WebIDE there was a wizard that helped you with this task. In BAS there is also a wizard, but only for Adaptions Projects. For a classic extension project, there is no wizard anymore, and you have to manually add your new service to the manifest.json. But it is quite simple. You have to add your new service as data source and then also as a model. When no model name is provided, it will be used as default model.

	"sap.app": {
		"dataSources": {
			"ZMY_NEW_SERVICE": {
				"uri": "/sap/opu/odata/sap/ZHCMFAB_LEAVE_REQUEST_SRV/",
				"type": "OData",
				"settings": {
					"odataVersion": "2.0",
					"localUri": "localService/metadata.xml"
				}
			}
		}
	"sap.ui5": {
		"models": {
			"": {
				"dataSource": "ZMY_NEW_SERVICE",
				"preload": true,
				"settings": {
					"defaultBindingMode": "TwoWay",
					"useBatch": true,
					"refreshAfterChange": false,
					"disableHeadRequestForToken": true,
					"defaultCountMode": "Inline",
					"metadataUrlParams": {
						"sap-documentation": "heading"
					}
				}
			}
		}
	},

[SAPUI5] Extension vs Adaption Project

I was wondering for quite some time, what the difference is between Extension Projects and Adaptions Projects. In the comments to this blog post, I finally found the answer from Oliver Graeff:

Adaptation projects are one of the capabilities of SAPUI5 flexibility, which lets developers, key users and end users adapt/extend SAPUI5 applications. Adaptation projects are the go-to solution for developer adaptation in SAPUI5 and are the ‘next-generation’ extension projects. Using the concepts of SAPUI5 flexibility, adaptation projects offer many more possibilities, such as extending SAP Fiori elements applications or extending apps without pre-defined extension points.

To check for a specific application, what the recommended extension approach is, simply go to the Fiori Reference Library, search for your app, choose the backend system (S/4 or Business Suite) and the current release version, navigate to Implementation Information and expand Extensibility. For example, My Overtime Requests on S/4HANA can be extended via an Adaption Project.

But on R/3, the only approach is an Extension Project.

Further helpful links:

Extending an SAP Fiori Application for an On-Premise System

Working with an Adaptation Project

Working with an SAPUI5 Extension Project

https://ga.support.sap.com/dtp/viewer/#/tree/1910/actions/24709

https://developers.sap.com/group.sapui5-adaptation-projects.html

https://www.youtube.com/watch?v=TVrUrem0UiM (min 40) https://github.com/SAP-samples/fiori-elements-opensap/blob/main/week4/unit3.md

https://sapui5.hana.ondemand.com/#/topic/a269671fc49e4c75920c108961bf31f2

[SAPUI5] Promisify an oData request

This is discussed for many years and unfortunately will not be implemented in the UI5 framework itself (see here). There are already different blogs describing how to build a wrapper for oData requests (for example here and here).

But with ES2024 it now got super simple to do this:

async function readData(model, entitySet) {
  const [promise, resolve, reject] = Promise.withResolver( )
  model.read(entitySet, {
    success: data => resolve(data),
    error: error => reject(error)
  })
  return promise
}

const user = await readData(oDataModel, "/user")

[SAPUI5] Model binding events

this.getView().bindElement({
				path: sObjectPath,
				events: {
					dataRequested: (oEvent) => {}, // Executed when a request to server is send
					dataReceived: (oEvent) => {},  // Executed when data from server is received
					change:(oEvent) => {},         // Executed everytime you do ElementBinding
				}
			})

The events for dataRequested and dataReceived are only fired, when data is requested or data is received from a backend. This is not the case, when the requested data is already available in the model from a previous backend call. In such situations, the change event comes in handy.

The same can also be done via XML:

binding="{
  path: '/myEntitySet',
  events: {
    dataRequested: 'onDataRequested',
    dataReceived: 'onDataReceived',
    change: 'onDataChange'
  }
}"

[SAPUI5] securityTokenAvailable

Just noticed, that with UI5 version 1.119.0 the getSecurityToken() function got replaced with securityTokenAvailable().

https://sapui5.hana.ondemand.com/#/api/sap.ui.model.odata.v2.ODataModel%23methods/getSecurityToken

https://sapui5.hana.ondemand.com/#/api/sap.ui.model.odata.v2.ODataModel%23methods/securityTokenAvailable

// Returns the current security token if available; triggers a request to fetch the security token if it is not available.
const token = this.getModel().getSecurityToken() // Deprecated

// Returns a promise, which will resolve with the security token as soon as it is available.
const token = await this.getModel().securityTokenAvailable()

[SAPUI5] Add your own Logout functionality to the Launchpad Sandbox

Use the attachLogoutEvent of the ushell container to trigger your approuter logout endpoint, that needs to be configured in your xs-app.json. The code in my launchpad.html looks like this:

    <script>
        sap.ui.getCore().attachInit(() => {

            sap.ushell.Container.createRenderer('fiori2', true).then(renderer => renderer.placeAt("content"))

            sap.ushell.Container.attachLogoutEvent(e => {
                e.preventDefault()
                window.location.replace('/do/logout')
            }, false)

        })
    </script>

This way, you can reuse the default logout dialog logic the launchpad provides.

For completeness, find also my approuter configuration and custom logout page below.

My xs-app.json:

{
  "welcomeFile": "index.html",
  "authenticationMethod": "route",
  "logout": {
    "logoutEndpoint": "/do/logout",
    "logoutPage": "/logged-out.html"
  },
  "sessionTimeout": 60,
  "routes": [
    {
      "source": "^/logged-out.html$",
      "localDir": ".",
      "authenticationType": "none"
    },
    {
      "source": "^/launchpad.html$",
      "localDir": ".",
      "authenticationType": "xsuaa",
      "cacheControl": "no-cache, no-store, must-revalidate"
    },
    {
      "source": "^/appconfig/(.*)$",
      "localDir": ".",
      "authenticationType": "xsuaa"
    },
    {
      "source": "^/user-api(.*)",
      "target": "$1",
      "service": "sap-approuter-userapi",
      "authenticationType": "xsuaa"
    },
...
  ]
}

My logged-out.html file, placed in the approuter folder next to the launchpad.html:

<!DOCTYPE html>
<html>

<head>
    <meta http-equiv="X-UA-Compatible" content="IE=edge" />
    <meta http-equiv="Content-Type" content="text/html;charset=UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Logged out</title>
    <style>
        h2 {
            font-family: "Arial", sans-serif;
        }
        .centered {
            position: absolute;
            top: 50%;
            left: 50%;
            transform: translate(-50%, -50%);
        }
    </style>
</head>

<body>
    <div class="centered">
        <h2>You are now logged out</h2>
    </div>
</body>

</html>