Rapid SAP App Development with Bowdark Fuse and Power Apps
Last week, we announced the general availability of Bowdark Fuse, a cloud connector solution which unlocks rapid SAP app development. Today, we’re going to show you how easy it is to create SAP applications using Microsoft Power Apps technology.
Just Add W̶a̶t̶e̶r̶ APIs
The lifeblood of any Fuse SAP app is an OData service. These could be OData services developed/delivered by SAP, custom APIs developed in-house by your ABAP development team, or generated APIs built on top of Core Data Services/HANA. Or, you can mix-and-match APIs. To Fuse, OData is OData, so it’s good either way.
To demonstrate how this works, we will leverage a basic OData service that exposes a handful of entities related to the SAP Customer Service (CS) module. As you can see in Figure 1 below, our entity model is mostly focused on service notifications, tasks, and attachments. This service is fully CRUD enabled — allowing users to not only search for notifications, but also create and update them, too.
Publishing the OData Service to Power Apps
Once our OData service is ready to go in SAP, we can publish it through the Fuse administrative portal as shown in Figure 2. At this point, we have a couple of options to expose the service to Power Apps:
- We can download an Open API definition of the service (sometimes referred to as a Swagger specification document) and use it to create a custom connector as described in the Microsoft Learn documentation here.
- We can map some of the key entities from the SAP OData service into virtual tables in Dataverse.
Although either option is viable, we recommend option #2 as it enables us to build apps using either canvas apps or model-driven apps (or both). It also unlocks the ability to leverage Fuse to develop self-service portals with Power Pages.
Figure 3 shows what a Fuse-based SAP virtual table looks like in Dataverse. To the app maker in Power Platform, these tables look just like regular tables built in Dataverse. However, things look very different underneath the hood. With Fuse virtual tables, the data is looked up on the fly via a call to the target OData service in SAP. So, for example, the live SAP Data shown in the preview pane in Figure 3 was provided via a query against the ZCS_NOTIF_SRV service we published earlier (see Figure 2). Similarly, any updates made to the data would be sent directly to SAP via the same OData service.
From a security perspective, Fuse supports end-to-end principal propagation (or SSO). This means that a user can only see the data that they are authorized to see in SAP. We are not reinventing the wheel with SAP security. So, in our contrived SAP Customer Service scenario, if you’re not authorized to see service notifications of a particular type (say in Transaction IW53), then you would not be able to view/edit them in Fuse/Dataverse, either.
The Power Apps Development Experience
Once we map the OData service entities into Dataverse as virtual tables, we’re ready to turn makers loose with building apps using Power Apps. Here, if we use model-driven apps, apps can come together very quickly. For example, if we need to create a responsive table showing SAP data, we can create a view using the what-you-see-is-what-you-get (WYSIWYG) view editor shown in Figure 4 below. Here, makers can drag-and-drop SAP fields onto the canvas, apply sort/filter conditions, and so forth.
Application screens are built in a similar fashion using the Form Builder tool shown in Figure 5. Once again, makers can drag-and-drop fields onto the canvas in a WYSIWYG development experience.
After the basic forms and views are defined, makers can begin incorporating these SAP screens into their model-driven apps. At this point, makers can take advantage of many of the built-in features of Power Apps to take their apps to the next level.
Why Power Apps?
Figure 6 and Figure 7 illustrate what a live Fuse-based Power App looks like to an end user working on a desktop browser. If you’re familiar with SAP’s Fiori design language, you might be asking yourself why wouldn’t you just build this app using say a Fiori worklist floorplan? And, if this was as far as we took things with our Power App, that’s probably an argument that has some legs. However, with Power Apps (and indeed the whole of the Power Platform), that’s not the end of the story.
In the upcoming sections, we’ll explore some of the key benefits of building on Fuse + Power Apps.
Built-In Features of Power Apps
Once we get our SAP data into Power Apps, we can leverage quite a few built-in features to enhance our apps and the overall user experience. For example, Figure 8 below illustrates some of the built-in personalization features of Power Apps views. Here, users can personalize the list columns, adjust filters, and perform keyword searches. Behind the scenes, these customizations are mapped to OData queries in SAP.
Not surprisingly, Power Apps also plays very nicely with Excel, making it easy to export/import data. There’s even an option to create a live Excel worksheet where users can edit records en masse in Excel and then upload the changes back to Dataverse.
Looking carefully at Figure 8, you can see that there are options to visualize the data using charts and/or Power BI (e.g., the Show Chart and Visualize this view buttons). These options can be combined with more advanced Power BI dashboards to create embedded analytics scenarios with minimal development effort.
For forms, makers/business analysts can define screen/business rules using the graphical business rules editor. As you can see in Figure 9 below, these business rules can be used to conditionally lock/unlock fields, set default values, show/hide fields, and even set required field constraints — all without requiring you to write a single line of code.
Mobility + Offline Support
Power Apps naturally support a responsive design. This means that they work equally well on desktops, tablets, and smart phones. For example, Figure 10 illustrates what our sample service notification app looks like when running on a smart phone device.
Although mobile users can simply pull up a Power App via their device’s browser, there’s also an option to run the app through Microsoft’s Power Apps player app which can be downloaded from the Apple Store, Google Play Store, or Windows Store. This player app unlocks some additional features that can be very useful for enterprise-grade mobile apps.
One of the more notable features here is Power Apps’ support for offline access. With a literal check of a box (see Figure 11), we can enable offline support for tables. Although offline support is (naturally) not supported for virtual tables, we can easily cache SAP data from virtual tables into staging tables in Dataverse, allow the user to transact offline, and then sync everything up once the user comes back online. There are no additional licensing costs or special middleware required.
Mash-Up Capabilities
Although our sample Power App was focused on providing users with a simple way to manage their assigned service notifications in SAP, we certainly don’t have to stop there. If we wanted to empower service technicians to operate in the field, we could incorporate many additional features to our app including:
- Support for notifications (e.g., whenever a notification or service order is created).
- Support for digital signatures and even digital payments.
- Integration with mobile device features such as the camera or GPS.
- Integration with additional apps such as Esri ArcGIS, Google Maps, or even the user’s Outlook calendar.
These days, Power Platform has over 1,000 connectors available, so the possibilities are almost endless.
Another interesting mash-up option is to blend SAP functionality like this into Dynamics 365 CRM modules. We reviewed this concept recently on the blog talking about real-time integration between Dynamics 365 Customer Service and SAP. This option enables customers to tap into modern CRM experiences while innovating around the edges with their SAP ERP core.
Looking beyond CRM, these mash-up capabilities are great for building industry solutions and/or line-of-business (LoB) apps that are “SAP adjacent” in nature. For example, an oil and gas producer might use Power Apps to create a LoB solution for upstream oil and gas processes and then use Fuse to integrate that solution with SAP financials on the backend.
Microsoft Teams Integration
Another option for hosting our Fuse-based Power Apps is to embed them in Microsoft Teams. This provides mobile users with a one-stop shop for transacting in the field — see Figure 12.
With Teams, the conversation can be bidirectional. For instance, Figure 13 shows an example of a dynamically generated adaptive card designed to alert the user responsible for a service order whenever selected user statuses are set in SAP. In addition to the information in the alert itself, the user can utilize the Reassign Order and Contact Customer buttons to perform follow-on actions — which could include opening up the service order in an embedded Power App.
Support for Business Analysts
One of the main benefits of having WYSIWYG designer tools like the ones demonstrated in Figure 4 and Figure 5 above is that they enable business analysts (BAs) and makers to perform routine app maintenance tasks on their own. For example, if a BA simply wants to add a new field or two, rearrange fields on the screen, change a few labels, or hide some old fields, they can do so without having to call up IT.
Put Fuse to Work for Your Business
Hopefully this demonstration has shown you the power of Fuse as it relates to rapid SAP app development using Power Apps. If you’re interested in learning more about how Fuse could be leveraged to accelerate SAP app development, please feel free to schedule a live demo with us or drop us an email at sales@bowdark.com. We look forward to learning more about your requirements.
