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>

[Fiori] Creating a Launchpad Plugin using BAS

Since there is no Wizard anymore for creating a Launchpad Plugin, as there was in WebIDE, you have to create it manually. The following two guides helped me create a Launchpad Plugin in BAS from scratch:
https://github.com/SAP-samples/fiori-custom-plugin-abap/tree/main
https://github.com/SAP-samples/launchpad-service-samples
In my scenario, I had to deploy to a normal S/4 HANA system, so I skipped all the Steampunk or WorkZone parts.

In the first sample, for some reason they use jQuery to call an OData Service, in the second sample no OData is called at all. But of course, an OData Service can be used in a Plugin the same way as you do in every other Fiori App. You just have to add your service in the manifest.json like you would normally do:

  "sap.app": {
    ...
    "dataSources": {
      "ZFLP_TEST_SRV": {
        "uri": "/sap/opu/odata/sap/ZFLP_TEST_SRV",
        "type": "OData",
        "settings": {
          "odataVersion": "2.0",
          "localUri": "localService/metadata.xml"
        }
      }
    }
  },
  ...
  "sap.ui5": {
    ...
    "models": {
      "": {
        "dataSource": "ZFLP_TEST_SRV",
        "preload": true,
        "settings": {
          "defaultCountMode": "Inline",
          "metadataUrlParams": {
            "sap-documentation": "heading"
          }
        }
      }
    }

And for i18n

  "sap.ui5": {
     ...
    "models": {
      "i18n": {
        "type": "sap.ui.model.resource.ResourceModel",
        "settings": {
          "bundleName": "ne.flp.plugin.flp_my_plugin.i18n.i18n"
        }
      }
    }

To activate the deployed Plugin, use these transactions:

  • /ui2/flp_conf_def → Define FLP Plugins → Create new entry
  • /ui2/flp_sys_conf → Make Plugin available system-wide
  • /ui2/flp_cus_conf → Make plugin available in specific clients
  • /ui2/flp → open Fiori Launchpad to test plugin

[Fiori] My Inbox – Tasks not appearing in Inbox

There are many reasons why a workflow task might not appear in the Inbox app. One reason I always forget to check is quite simple.

Check whether a scenario is configured!

Simply open the Tile configuration and check the Parameter field. If there is a scenario, it would be something like scenarioId=EHS_HS_HAZMAT instead of allItems=true.

If a scenario is in use, you can find more about it in the customizing here:

In a scenario, a restriction to certain workflow tasks can be configured.

More information can be found here:
https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/8308e6d301d54584a33cd04a9861bc52/68c4379a35f644f6b3a73428594d6c3f.html?locale=en-US&version=LATEST
https://community.sap.com/t5/technology-blog-posts-by-sap/sap-fiori-for-sap-s-4hana-fiori-my-inbox-part-1-activation/ba-p/13326175

[Fiori] Abwesenheitsantrag in Inbox für nicht genehmigungspflichtige Abwesenheitsart

Kürzlich hatte ich die Situation, dass eine Führungskraft einen Abwesenheitsantrag in der Inbox hatte für eine Abwesenheitsart, die eigentlich nicht genehmigungspflichtig ist. Es hätte also gar kein Genehmigungsworkflow gestartet werden dürfen. Merkwürdigerweise war die beantragte Abwesenheit auch bereits im Infotyp verbucht. Auch konnte man den Antrag in der Inbox weder Ablehnen noch Genehmigen, beides lief auf ein Fehler.

Wie kam es also zu dieser Situation?

Der Mitarbeiter hatte einen Antrag mit einer genehmigungspflichtigen Abwesenheitsart gestellt, wie z.B. Urlaub.

Bevor der Genehmiger diesen Antrag bearbeitet hat, wurde der Antrag vom Antragsteller jedoch nochmal abgeändert. Dies ist über das Stift-Symbol möglich. Dabei wurde dann eine nicht genehmigungspflichtige Abwesenheitsart gewählt, wie z.B. Abbau Überzeit.

In diesem Fall wird der Antrag ohne Genehmigungsprozess durchlaufen und die Abwesenheit wird kurz darauf direkt in den Infotyp geschrieben durch den Verbucherreport.

Jedoch gab es ja bereits einen laufenden Workflow mit einem Workitem in der Inbox des Genehmigers und dieser wurde nicht beendet. Stattdessen wurde in dem Workitem sogar die beantragte Abwesenheitsart aktualisiert, obwohl für diese Abwesenheitsart ja gar keine Genehmigung erforderlich ist und sogar bereits in den Infotyp geschrieben war.

Auch in der Antragsdatenbank spiegelt sich das Problem wider. Der Antrag stand dort im Status ‘POSTED‘ und der Workflow-Status auf ‘STARTED‘.

Ich habe das Szenario dann mit einer Zweiten, nicht genehmigungspflichtigen Abwesenheitsart getestet, also Urlaub erfasst und vor Genehmigung die Abwesenheitsart geändert. Hier wurde jedoch der laufende Workflow korrekterweise beendet.

Als ich beide Abwesenheitsarten in der V_T554S_WEB verglichen habe, ist mir aufgefallen, dass bei der problembehafteten Abwesenheitsart ein Workflow gecustomized war, obwohl diese ja nicht genehmigungspflichtig ist. Der Workflow wurde jedoch nur verwendet, um eine Info-Mail zu versenden.

Die Workflow Checkbox ließ sich leider nicht deaktivieren (vermutlich weil es schon Anträge zu der Abwesenheitsart gibt). Aber es scheint, als führt dieses Workflowcustomizing dann zu Inkonsistenzen, wenn in einem laufenden Antrag von einer genehmigungspflichtigen Abwesenheitsart zu einer nichtgenehmigungspflichtigen gewechselt wird.

Dieser Post nur als Erinnerung, falls ich nochmal in so eine Situation laufe. Vielleicht habe ich dann die Chance, es zu verifizieren.

[Fiori] MyInbox – Leave Request Approval: Genehmigung erfolgreich, aber mit Fehler für Workflow 21500001

Beim Einrichten der 1-Stufigen Genehmigung von Urlaub mit dem Standard Workflow 21500001 bin ich in folgenden Fehler gelaufen in der Inbox nach Drücken des Genehmigungsbuttons.

Merkwürdigerweise wurde der Urlaubsantrag erfolgreich genehmigt und trotzdem gab es eine Fehlermeldung. Nach kurzem debuggen war auch klar warum. Der Antrag wurde erst erfolgreich genehmigt und dann wurde das gleiche Coding nochmal durchlaufen und führte zu einer Kollisionsmeldung.

Daraufhin habe ich mir den BAdI /IWWRK/BADI_WF_BEFORE_UPD_IB angeschaut. Dort konnte ich zwei Implementierungen zum Thema Leave Approval finden und in beiden war der Workflow 21500001 als Filterkriterium eingetragen. Das erklärte, warum die Genehmigungslogik zweimal durchlaufen wurde.

Daraufhin habe ich nach einem Hinweis gesucht und folgenden gefunden: 2658528. Der beschreibt zwar eine andere Fehlermeldung, aber die Lösung war genau die Aussage, die ich gesucht habe.

Die Implementierung HRMSS_LEAVE_APPROVAL musste also deaktiviert werden. Ich habe das über die SE19 gemacht, auch wenn das bedeutete, dass ich nun als letzter Änderer eines SAP-Objekts drin stehe. Anscheinend geht es auch über den Funktionsbaustein ENH_BADI_IMG_ACTIVITY_TOGGLE wie hier beschrieben.

[Fiori] FPS – Feature Pack Stack

In the SAP Fiori Apps Reference Library, you have to select the target system on which the app is to be installed. You can choose between different major releases and also between different FPS’s.

These feature packs are smaller, targeted updates delivered between major releases of S/4HANA. To check if a Feature Pack is installed on your system, go to

System → Status → Button Product version → Tab Installed Product versions → Column SP / FTP Stack

In this case, no additional FPS is installed.

[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"
					}
				}
			}
		}
	},