In late January I released a blog introducing version 2.0 of the SAP Cloud Platform SDK for Android. As part of the blog I introduced a new feature to the SDK, the Flows framework. As you can tell from my brief description there, I'm a big fan - so much so that today I'd like to spend a few minutes discussing the topic in more detail. At the end I'll provide links to additional content so you can continue to learn more about the topic.
Before we go deeper into Flows itself, let's start with a discussion of the problem that it's trying to solve - app onboarding (there are aspects of Flows, but app onboarding is the most important). Okay, sounds good, right....but what's app onboarding?
The term "app onboarding" refers to the process that needs to occur after a user installs an app (or it is installed by an EMM on the user's behalf), but before they get access to business data. And while this process is fundamentally the same regardless of whether the app is intended for a consumer (B2C) or an employee (B2E), the B2E use case likely has more processes related to enterprise security than the B2C case. Think about the last time you installed a new app and ran it for the first time - did you need to authenticate? Acknowledge a EULA? Grant consent for usage collection? Perhaps even establish an app level passcode? You know you have!
Now think about it from a slightly more technical level. How does the app even know where it gets its business data from? How does it know how to authenticate the user? Where does it get its passcode policy? How do I configure the correct log level? How does the app know not to prompt you for this information every time the app is run? Some of the implementation details can be hard coded, but on the mobile team we generally recommend against doing this - but you have to get the information from somewhere.
All this is obviously doable with the Android SDK (and the IOS SDK, which has had Flows for a while now) and Mobile Services. It takes is a good programmer with the knowledge and willingness to write the code. So what's the problem?
Nothing, necessarily, but we want to do better.
The code I mention is code you have to maintain. More code equals more knowledge aquisition, initial development and subsequent maintenance costs. And let's be honest - this code's only relation to the business process in that the app onboarding process must be completed before access to the business data is granted. At SAP, we don't know the business problem you're trying to solve, but we do know what it takes to onboard a user / device to the business problem.
Enter Flows, a framework designed to simplify the app onboarding process and reduce the code required to connect your user to his business content.
I intentionally used the term "process". In this context, its something that's fairly well defined and can be relatively easily broken up into a series of discrete (and more importantly, enumerable) "steps". For example, the password screen can be broken into two "steps". Step 1, download the password policy (others policies too) from Mobile Services. Step 2, present the views to the end user to enable them to establish the passcode in accordance with the downloaded policy. There are a couple things to notice in this example. First, not all steps are visible to the end user, and second, some steps are dependent on other steps completing successfully.
So how does Flows help? First, we provide you a list of app onboarding Steps as part of a re-usable framework. You can find a complete list of steps here. Custom steps, if necessary, can be defined by the developer. Here's the most important part - each provided step has a default implementation. Unless you need something special (you probably don't), the Step can be used as-is. The implementation was created using SAP best practices and governance and is maintained by SAP.
Next, we provide you a Flow object which allows you to specify the steps you want to include and the order in which they should be executed.
Third, we deliver a FlowManagerService object that executes the passed Flow, in the order prescribed, giving the developer the opportunity to supply custom logic (if necessary) at each step's success or failure.
You can think of it kind of like this:
And that's it. By using Flows, you can focus your development project (and your developer) on addressing the business needs of the end user while we help with the technical needs of the app itself. Everybody wins!
One last comment - I focused exclusively in this blog on the onboarding flow, But Flows isn't limited to just the onboarding scenario - reset, restore and change use cases are also supported.
Thanks for sticking with me through this valuable topic discussion. I realize I didn't actually show ANY code today (I know, boooooo). To get a hands on experience with Flows, I strongly recommend you check out Dan Van Leeuwen's set of developer tutorials.
And while I mentioned it in the body of the blog, here's a link to more information about Flows itself - https://help.sap.com/doc/c2d571df73104f72b9f1b73e06c5609a/Latest/en-US/docs/flows/Overview.html.
Get in the Flow!
Before we go deeper into Flows itself, let's start with a discussion of the problem that it's trying to solve - app onboarding (there are aspects of Flows, but app onboarding is the most important). Okay, sounds good, right....but what's app onboarding?
The term "app onboarding" refers to the process that needs to occur after a user installs an app (or it is installed by an EMM on the user's behalf), but before they get access to business data. And while this process is fundamentally the same regardless of whether the app is intended for a consumer (B2C) or an employee (B2E), the B2E use case likely has more processes related to enterprise security than the B2C case. Think about the last time you installed a new app and ran it for the first time - did you need to authenticate? Acknowledge a EULA? Grant consent for usage collection? Perhaps even establish an app level passcode? You know you have!
Now think about it from a slightly more technical level. How does the app even know where it gets its business data from? How does it know how to authenticate the user? Where does it get its passcode policy? How do I configure the correct log level? How does the app know not to prompt you for this information every time the app is run? Some of the implementation details can be hard coded, but on the mobile team we generally recommend against doing this - but you have to get the information from somewhere.
All this is obviously doable with the Android SDK (and the IOS SDK, which has had Flows for a while now) and Mobile Services. It takes is a good programmer with the knowledge and willingness to write the code. So what's the problem?
Nothing, necessarily, but we want to do better.
The code I mention is code you have to maintain. More code equals more knowledge aquisition, initial development and subsequent maintenance costs. And let's be honest - this code's only relation to the business process in that the app onboarding process must be completed before access to the business data is granted. At SAP, we don't know the business problem you're trying to solve, but we do know what it takes to onboard a user / device to the business problem.
Enter Flows, a framework designed to simplify the app onboarding process and reduce the code required to connect your user to his business content.
I intentionally used the term "process". In this context, its something that's fairly well defined and can be relatively easily broken up into a series of discrete (and more importantly, enumerable) "steps". For example, the password screen can be broken into two "steps". Step 1, download the password policy (others policies too) from Mobile Services. Step 2, present the views to the end user to enable them to establish the passcode in accordance with the downloaded policy. There are a couple things to notice in this example. First, not all steps are visible to the end user, and second, some steps are dependent on other steps completing successfully.
So how does Flows help? First, we provide you a list of app onboarding Steps as part of a re-usable framework. You can find a complete list of steps here. Custom steps, if necessary, can be defined by the developer. Here's the most important part - each provided step has a default implementation. Unless you need something special (you probably don't), the Step can be used as-is. The implementation was created using SAP best practices and governance and is maintained by SAP.
Next, we provide you a Flow object which allows you to specify the steps you want to include and the order in which they should be executed.
Third, we deliver a FlowManagerService object that executes the passed Flow, in the order prescribed, giving the developer the opportunity to supply custom logic (if necessary) at each step's success or failure.
You can think of it kind of like this:
And that's it. By using Flows, you can focus your development project (and your developer) on addressing the business needs of the end user while we help with the technical needs of the app itself. Everybody wins!
One last comment - I focused exclusively in this blog on the onboarding flow, But Flows isn't limited to just the onboarding scenario - reset, restore and change use cases are also supported.
Thanks for sticking with me through this valuable topic discussion. I realize I didn't actually show ANY code today (I know, boooooo). To get a hands on experience with Flows, I strongly recommend you check out Dan Van Leeuwen's set of developer tutorials.
And while I mentioned it in the body of the blog, here's a link to more information about Flows itself - https://help.sap.com/doc/c2d571df73104f72b9f1b73e06c5609a/Latest/en-US/docs/flows/Overview.html.
Get in the Flow!
- SAP Managed Tags:
