SAP Cloud Platform Mobile Services Development Options
In this blog post I would like to shed some light on the development options at your disposal when building mobile apps. There is an abundance of use cases that dictate how an app needs to be built, and SAP offers a multitude of tools and approaches to achieve that goal. In the following sections, I am going to introduce the various pieces of technology and their strengths on a high level. Finally I am going to assume the role of a decision maker and give some guidance on when to pursue which approach. More detailed information on the individual topics can be found in dedicated blog topics, which I am going to link as they become available.
Fig. 1: Application development options around SAP Cloud Platform Mobile Services
2018-06-05: Mentioning SAP Cloud Platform SDK for Android in Native Apps section
Table of Contents
SAP Mobile Cards
Our Micro App platform “SAP Mobile Cards” (formerly known as “SAP Content to Go”) allows you to mobilize virtually any data source with little to no custom development. Each piece of information is rendered as an individual card and displayed in the personal Passbook-style iOS* Mobile Cards app. The data displayed in the app is fully offline-enabled and Mobile Services will automatically track changes and push updates to the individual users. Whenever additional context for a card is required, users can easily navigate back from the currently displayed card to its origin application. In addition, the Mobile Cards app comes with additional commonly expected features, such as the ability to share cards between users – of course only those that they are allowed to see.
In order to enable Mobile Cards in Fiori applications, no additional development is required. Building on top of Fiori Smart Templates, we provide a Fiori Launchpad plugin that allows you to easily enable Mobile Cards in your apps simply by means of configuration. And if you are looking for a more flexible means of integration Mobile Cards into your system, there are also back-end facing APIs that allows you to easily publish data in the form of Mobile Cards cards or even actions that can be performed on those cards. Last but not least, if you are not happy with the default look and feel of the cards, you can easily design custom templates in the Mobile Services administrator cockpit.
*Android support is a roadmap topic
Fig. 2: An example of a Mobile Cards card
SAP Mobile Development Kit
The resulting application models can be loaded into the Mobile Development Kit iOS application, where a native UI is rendered based on the application definition. Device-native features, such as contacts, and sensors, can be leveraged by means of platform-independent APIs that are exposed via the client application. In addition, the client implements the established Mobile Services features, such as Push and Offline.
Please note that we just released the first version of the Mobile Development Kit, so stay tuned for more features and content to come!
*Cross-platform applications are a roadmap topic
Fig. 3: Mobile Development Kit development and technology
Web apps are inherently cross-platform due to browsers being available on all major platforms, and they are very easy to build and distribute. Frameworks such as SAP UI5 even make them responsive, so that it is possible to target both desktop and mobile devices with the same app. A great example of this style of application is what we provide with our Fiori applications, which you can also build on top of the tools that are integrated with the Web IDE. While the browser largely isolates web apps from the underlying platform in a way that they can barely leverage native features, such as native Push, Mobile Services can act as a secure proxy for your internally available apps. This way you can expose web apps from your intranet to eligible employees on the internet, without putting your data at risk.
Fig. 4: High-level web app architecture. Please note that the “Mobile Web App” is only hosted on the Cloud Platform, but actually runs on the device.
In contrast to web apps, that are built to run in browsers and will, therefore, run on any platform, native applications are built to run on one specific mobile platform. While this typically makes development for multiple platforms more costly than going for web apps, native apps offer best performance and platform integration. If you need to secure your data with biometric features, access device sensors or need a blazing fast user interface, native apps are your best friend.
In order to integrate with Mobile Services capabilities such as Push and Offline, we provide the SAP Mobile Platform SDK 3.0, which is available for Android, iOS and Windows. It comes with a number of reuse components for common tasks such as authentication, enables you to transparently take your OData data sources offline, and provides a number of utilities that makes it easier to integrate with Mobile Services overall.
Furthermore, with the SAP Cloud Platform SDK for iOS and SAP Cloud Platform SDK for Android, we released modernized SDKs written in Swift and Java, respectively, and that were developed in cooperation with Apple and Google. They implement the same server-side features as the Mobile Platform SDK but offers additional extension concepts that enable you to build customizable standard apps. In addition, we put a lot of effort in the tooling around the Cloud Platform SDKs, which includes proxy class and sample code generation based on your Mobile Services application configuration. With this SDK, we also released the SAP Fiori for iOS Design Guidelines, and implemented native UI components to enable you to easily implement native Fiori-style apps on iOS and Android.
Fig. 5: An example of a screen implementing the SAP Fiori for iOS Design Language.
Fig. 6: An example of a screen implementing the SAP Fiori for Android Design Language.
Fig. 7: High-level Cordova app architecture
Now, speaking of SAP Fiori, there is a number of additional consumption options at your disposal. First, however, I would like to introduce the notion of “packaged” and “online hybrid applications”. Cordova lets you specify from where the application should be loaded that is displayed in the container. Typically, the assumption is that your app is packaged into the Cordova container, which means that all of the application code and assets are physically on the device. However, it is also possible to specify a remote URL pointing, e.g., to a Fiori Front-end Server, from which the WebView will load the application itself. There are some implications to those approaches:
Online hybrid apps allow you to open applications from both a browser and a Cordova application. While this makes distribution very easy, it does mean that the app should be context-aware. Otherwise, the app would break if it tries to access Cordova APIs that are unavailable in standard browsers. However, it is not possible to take these applications offline, because all your users are going to see when there is a network outage, is a blank screen.
Fig. 8: Online hybrid applications, using the example of SAP Fiori Client (see below). Note how the web app is hosted on the Cloud Platform, while the hybrid container is installed on the device.
Packaged hybrid apps, on the other hand, can easily be offline enabled. For one thing, all of the application code is on the device, which means that it can handle network failures, such as users experience under bad network conditions. Secondly, the Kapsel SDK allows to take OData-based data sources offline, which can then be accessed by the application even when there is a network outage. This would not work with online hybrid apps since even though the required data is on the device, the application itself needs to be downloaded online from servers.
Fig. 9: High-level packaged hybrid application architecture. Note how the application is physically located on the device, and only data flows between the device and the Cloud Platform.
Lifecycle-wise, both types of hybrid apps are similar in that the Cordova container needs to be deployed to an app store at least once. Online hybrid apps can then easily be updated by deploying a new web app version to the origin web server. Packaged apps, however, need to be deployed via the app store again. Alternatively, there is the Mobile Services AppUpdate feature that allows you to update the packaged application contents via our cloud platform, which alleviates one of the most common issues with packaged applications.
SAP Fiori Client
The SAP Fiori Client is a freely available standard application that enables you to run web apps as online hybrid apps. As opposed to typical Cordova applications, where the origin of the web app to display is hard-coded, the Fiori Client lets you specify an endpoint URL of the application to display. As described above, that will enable any app opened in the Fiori Client to access device-native features. Since the Fiori Client comes with the most commonly used Kapsel and Cordova plugins, it is a potential way to improve the user experience of your web apps and integrate with Mobile Services without needing to implement your own Cordova container. Due to its optimized caching mechanisms, applications feel more stable and faster since UI components are reloaded less often during user interaction. In addition, combining the Fiori Client with Mobile Services enables your users to securely access applications from the intranet without resorting to VPN. The additional monitoring capabilities also make it easier to maintain control over the data and applications leaving your premises. If you require additional features or want to customize the appearance, there is a Custom Fiori Client template at your disposal in the Mobile Platform SDK.
Fig. 10: A Fiori Launchpad opened in the Fiori Client.
What to choose?
With that amount of development options at your disposal, picking the right tool for the job at hand becomes somewhat tricky. Alas, there is no silver bullet, and it depends very much on the use case which option will yield the best results. Therefore I would like to give a couple of guiding questions that will help you decide which approach to pick. I also provide a summary by means of a table below.
The topic “Hybrid vs. Native” has also been discussed in a dedicated blog post by Martin Grasshoff.
Are you targeting several platforms or only a single one?
Native development is fine for single-platform deployments but becomes costly when multiple platforms are targeted. In those scenarios, any of the other approaches may be preferable.
Is a native look-and-feel important to your users or is a web interface sufficient?
Native applications, Mobile Cards and Mobile Development Kit work best for offering your users what is considered a “native” UI experience. Many users consider web-based UIs alien when compared to the average app, and therefore it may not be the best option. However, web-based UIs are cheaper to develop, so when your users are fine with them, hybrid apps or web apps may be the way to go.
Are offline availability and stability a strict requirement or will online-only do?
This is one of the most underrated questions, since Mobile really is about accessing your data anywhere, under unpredictable network conditions. Failing to meet users’ expectations regarding the availability of your application even under poor network conditions puts adoption at risk. However, offline-enabling your data requires additional planning, e.g. around dealing with process-related issues such as concurrent modification in CRUD scenarios. Therefore validating the requirement is an important step, since for occasional use online-only access may be sufficient.
If Offline is required, Mobile Cards is your best bet since it offline-enables your data out of the box. Mobile Development Kit, native and packaged hybrid apps can also be offline-enabled by means of the Offline OData support in our SDKs, while giving a higher degree of freedom than Mobile Cards. On the other hand, online hybrid apps and web apps, especially when used in conjunction with Fiori Client, can provide a satisfactory online experience when offline enablement is not required.
Is the app business-critical or only occasionally used?
Business-critical apps have very high requirements concerning availability, performance, and stability of an application, whereas occasionally used apps (or “productivity apps”) do not require the same amount of meticulousness. As an example, there is little business impact if a purchase order approval app cannot be used without an active network connection. On the other hand, a failing service technician app can cost you several man-days worth of working time. Depending on the criticality of the use case, it may make sense to invest in a fully offline-enabled, blazing fast native application rather than in a cheap but unreliable web app. For anything in between these extremes, Mobile Cards and Mobile Development Kit provide you with tools to quickly mobilize data and to develop stable and fast applications.
Is a super fast user interface required or are your users okay with slight delays?
Another aspect to consider is the responsiveness of the user interface. Let’s face it, there is nothing faster than a native application, and if your users’ activities are centered around an unresponsive web app, they sure are not going to be happy. If you require response times of just a few milliseconds, consider Mobile Cards, Mobile Development Kit or native applications. You should also keep offline enablement in mind. If those aspects are not an issue, a hybrid or web app may suffice.
Is freestyle development required or will a framework address your needs?
To what degree do device-native capabilities matter?
As was pointed out in the discussion of web apps vs. native apps above, it is nigh impossible to have a web app leverage the native features mobile devices have to offer. To some extent, web standards are catching up so that it is possible to interface with the location service and even the camera. The majority of features, however, are only accessible by means of hybrid and native applications, and native apps clearly have an edge when it comes to very specific capabilities that are not commonly available across platforms. Mobile Cards gives you little flexibility but does implement some basic features such as Push and Sharing. Mobile Development Kit and Fiori Client apps can interface with whatever capabilities are exposed in the container application, and additional features can be included in custom clients.
Is time to market a driving factor?
Typically the decision is not purely user-driven, but business factors come into play at some point. Time to market is one such factor that is especially important in Mobile scenarios since the Mobile ecosystem is rather fast-paced when compared to other development areas. In order to minimize time to market, Mobile Cards and Mobile Development Kit are clearly the tools of choice, followed by web apps, hybrid apps and, finally, native apps.
|Cross-Platform (Android+iOS)||UI Performance||Offline||Customizability||Capabilities||Time to Market|
|Mobile Card Kit||++||++||++||—||–||++|
|Mobile Development Kit||++||++||++||+||+||+|
|Packaged Hybrid App||++||–2||+||–||+||–|
Fig. 10: Comparison of the various options with respect to some select qualities. The range goes from — (least suitable) over o (neutral) to ++ (most suitable). Fiori Client and Online Hybrid Apps have been collapsed into one category. Cross-Platform: Ability to run on Android and iOS. UI Performance: Time to content and responsiveness of UI. Offline: Suitability to build for network resilience. Customizability: Ease of and degree of freedom when customizing by configuration or code. Capabilities: Ease of access of low-level platform APIs.Time to Market: Difficulty of building an MVP in a typical customer setting.
1Fiori apps run in Fiori Client may show higher UI responsiveness than in browsers due to optimized caching
2Packaged Fiori apps may have better perceived stability and responsiveness due to locally stored UIs, but can not increase the execution speed of the UI or business logic as such.
3Time-to-market heavily reduced by tooling (SDK Assistant)
2019/02/25 Updated comparison table to reflect current state of roadmap. Hopefully also improved readability.
Thanks for the great overview, Michael!
Very informative presentation. Thank you!
Short, powerful and extremely useful ! Thanks @michael.jess
First and very good blog I have seen which connects all the different "elements" on mobile app development!
Micheal, thank you for this informative blog.
One area which I am missing and which will play big role in decision making process is the licensing costs. Current pricing model for Mobile Services seems to be based on "per user" formula and various development options make it slightly confusing.
Are mobile devices registered with Mobile Services classified as "users" of SAP Cloud Platform and license is paid for each device? If that was the case, mobile friendly Web Apps deployed on SAP Cloud Platform without Mobile Services could become much more interesting option despite obvious limitations.
Would you mind clarifying if with any of the methods you described here the devices onboarded by Mobile Services automatically become classified as users from licensing point of view?
Licensing questions are really tricky, because the terms may vary based on your sales region. I will try to answer that one, but please keep in mind that you should verify this with your local Sales or Account Representative.
Generally speaking (and with the disclaimer out of the way), when we say "users" we are in fact referring to actual individual persons. That means that when one person has three devices, you would only have to purchase a single license for that user. On the other hand, when three users share one device, you still have to purchase three user licenses. This is regardless of the actual development scenario, but I can see how this is confusing with web apps that cannot quite put the "meat" of the platform to good use. This is why I like to say that pure web apps are a sort of corner use case, where you are really just interested in using Mobile Services as an authentication proxy, in addition to other use cases. Purchasing Mobile Services just for that purpose may be somewhat over the top, but it may make sense when additional apps are being planned down the road.
Thank you for prompt response.
It is sad to say that based on your explanation I feel that SAP shot themselves in a foot as I can't imagine big companies wishing to use Mobile Services to deploy mobile apps to a bigger community, let alone using it for B2C scenarios. The latest SAP vs. Diageo ruling may be the final nail in the coffin as even connecting via web apps may be deemed inappropriate from licensing point of view.
I feel sorry for you guys at HCPms because what you are doing is very cool, but it must be understood that people using mobile devices should be classified differently from standard HCP users as the functionality they use is a fraction of what the whole platform offers. We should be reading valuable blog posts like this one thinking which development method is the most suitable for our scenarios without worrying about the price tag associated with deploying apps to a wider population.
Unfortunately as it stands the "SAP content to go" is a platform not only for micro apps but also for micro user base.
I think there is a slight misconception. Let me try to individually address your statements:
I assume this is related to your previous remark concerning user-based licensing. To my understanding, there is a dedicated B2C offering which has a different pricing structure than the "regular" offering. I would like to use this opportunity and repeat my recommendation to check with regional Sales in order to determine how much your scenario would actually cost.
I think the confusion herein lies in that you do not need to use Mobile Services in order to build a responsive web app that can be displayed on mobile devices. What I was saying is, there are very specific B2E scenarios in which Mobile Services may function as a secure proxy. Those would typically be intranet applications that are available to a select set of employees. Any other app can just be exposed directly from within Cloud Platform.
This one is a bit of a puzzler as well: Mobile Services is an individually subscribable service, among many others. You do not have to purchase subscriptions to "what the whole platform offers" in order to implement mobile scenarios, so you can actually tailor your subscriptions to what you need for the scenario at hand.
I hope that those clarifications remediate at least some of your concerns.
Let me respond to some of your comments first and then try to put things into perspective.
To my understanding, there is a dedicated B2C offering which has a different pricing structure than the “regular” offering. I would like to use this opportunity and repeat my recommendation to check with regional Sales in order to determine how much your scenario would actually cost.
This is correct however, the dedicated B2C offering can only be used if the client can quantify orders which then become the chargeable item (instead of Named Users). The are a lot of scenarios where orders are not used.
I think the confusion herein lies in that you do not need to use Mobile Services in order to build a responsive web app that can be displayed on mobile devices.
I understand that but I would like to host my mobile apps on SAP Cloud Platform. How can I be sure that SAP will not try to classify the users of those web apps accessed on mobile devices as Named Users of the platform? As much as I appreciate the regional differences in license costs, the definition of Named User must be consistent regardless of the location. Let me just say that I keep getting mixed messages in relation to that.
You do not have to purchase subscriptions to “what the whole platform offers” in order to implement mobile scenarios, so you can actually tailor your subscriptions to what you need for the scenario at hand.
Here is when we get to the point where real life example may help to see why I feel that development methods are very highly linked with the licensing costs and how difficult it is to overcome the obstacles.
The loud message about HANA Cloud Platform was that it could be used by thousands of developers who can easily implement their ideas and immediately monetize on their solutions. As a small software house we we thrilled and technically the HANA Cloud Platform looked like a great enabler. Our mobile solution used to connect directly to SAP Gateway and now we were able to offer more mature architecture with tight security, full offline and push notifications capability. On top of that we could expose data from on-premise to HANA Cloud and avoid using on-premise resources to analyse data that could now be synched with the cloud. In essence both us and our clients who saw our PoC were excited. Now comes the reality check.
As all users of the old mobile app which exchanged data with SAP Gateway were Named Users, there were no issues with licensing. However, introducing HCP with Mobile Services proved to be clunky. Our clients had no intention to purchase HCP for their enterprises and pay extra fees for each user connecting their mobile device, as many were using it rarely. Additional resources to administer data exchange between HCP and on-premise would also be needed. Hence my company started exploring options to take ownership of the HANA Cloud Platform and connect our clients' systems to our instance of HCP. According to local Sales team mobile devices registered on Mobile Services would be classed as Named Users and in consequence incur full cost. It is fair to say that our fees per user that our clients had to pay us were a fraction of what the HCP's cost per user is so we had to quickly abandon this idea.
We made our app work as a web application hosted on HCP (without Mobile services) and this would allow us to purchase resource based package. We did not have offline, Push option was limited and the biggest downside was a difficulty to identify devices connecting to HCP. But we only had to pay for the resources used, which was mainly related to the amount of data we would expose from our clients' on-premise systems. Things were looking promising and we wanted to take this route until the next huge blow - SAP vs. Diageo ruling. After this litigation no client, and I mean no one, wanted to speak to us about exposing data from their system to the cloud. Ironically, it is SAP's own cloud and SAP is the biggest loser here. Sadly I don't see it getting any better until SAP makes a clear distinction between Named Users and mobile devices (including IoT) in the licensing strategy. It is rather pathetic (sorry I can't find a better word) that we found bypassing HCP and Mobile Services the most viable option for our customers despite so much development effort from people like yourself who try to build a solution that addresses the needs of mobile generation.
I see. Thanks for sharing this story, I think this goes a great length to explain how you came to this conclusion. I appreciate straight and honest feedback like that because this is what we need to know in order to address shortcomings in our offering.
So far I have not realized that you were, in fact, reselling the platform, and I do think that our partner program might be the right thing for your use case. I have reached out to our partner management team and they are keen on discussing matters discretely with you. If you don’t mind, I’d suggest continuing this discussion via PMs.
Edit: I think we need to follow each other in order to exchange PMs.
The article is explained very well.Thanks for sharing such a informative blog.It will be very help .Let me introduce some more interesting article on hybrid vs native app.To know more:http://bit.ly/2Ki4bHA
Excellent article Michael Jess . We have a SAP UI5 that that our users are very happy with - they are running this in Internet Explorer 11 which is the company standard. They would like us to add offline capabilities. In terms of our options on Windows, to have this app offline enabled, can we use the Hybrid application toolkit for this? We had built a Hybrid app almost two years back and at that point only iOS and Android were supported - we had built this for iOS. Is there support for Windows through the SAP Hybrid Application Toolkit now? We are also exploring the MDK - but that seems to only be supported for iOS right now. The use case is the the users will go to client sites and will need to fill in their testing data and save this - even if they have no connectivity.
I would appreciate your feedback.
First of all, thanks for your kind words, and also for reminding me that for some reason, the table hasn't been updated to reflect that MDK actually is cross-platform now. Mind you, that doesn't include Windows, because we no longer consider that an important platform for new products due to Microsoft pulling out of the business. I am stressing the "for new products" bit here because Kapsel, our Hybrid SDK, still supports Windows. Now, what's striking me as odd is the "IE 11" bit - are we really talking about Mobile apps, or are you meaning to discuss desktop apps?
Hi Michael - thanks for your reply. Currently, we have built this custom SAP UI5 app that allows our users to enter in testing notes. They run this on their laptops on IE 11. They would like to offer the offline support for this app. So without building an IOS or Android version, we would like to build the offline feature so that they can run the app on their windows laptop. If we cannot do this with MDK, we should be able to do this with the Hybrid SDK right? We used the Hybrid application toolkit to build offline mobile app for our client for IOS and Android but did not do this for Windows. Are there any good articles for building Cordova SAP apps with offline for Windows? Another alternative we are looking into is the tablet option of iOS.
So I can think of two or three directions in which to take this:
Thanks for your reply.
We will look into option 1 and see if we can use the built in databases on the browsers.
I think option 2 is probably the best approach we have for now on the Windows platform. We should be able to use the Hybrid App Toolkit with the Windows Platform option. We have done this with iOS and Android - but not with Windows. If you have any reference articles for developing Hybrid Apps for Windows, that would be helpful. I will review the articles that you referenced - I have looked at these before. For our client, we had built the iOS Hybrid app using Xcode. For Windows, I am looking into the approach - but I am assuming we would need a Visual Studio or Visual Studio Code environment that we need to integrate it for the build.
Option 3 may be the best option for the rich functionality if the business is open to have IPads as the way to enter offline data. I will follow up on that.
Well, no, there is no Windows-specific content because it doesn’t really make sense: To us, it’s all “Cordova”, no matter the platform. You may refer to third-party docs for general, platform-specific notes if that’s what you’ve been looking for: https://cordova.apache.org/docs/en/latest/guide/platforms/windows/
Thanks Michael - we are working on the getting a build that we can install on the Windows platform. Currently, we are looking at creating an offline version of the app along with the Hybrid Application toolkit and specifying this for Windows. Once we have this in place, we should be able to import the project content into a Visual Studio Cordova project and then build it. That's where there are some open questions but if there are any subtleties or tricks to this, then I may contribute a blog.
I appreciate your help.
I can give you maybe one more pointer - I wrote a guide last year on setting up Continuous Integration with Cordova apps, and this includes both the related manual steps (probably easier to understand how things play together) and also a pointer to a colleague's blog who is elaborating on Offline enablement of those apps. Again, this is platform-agnostic, but it may be helpful: https://developers.sap.com/tutorials/ci-best-practices-mobile-cordova.html
Thanks Michael - we are now able to build the app on Cordova Windows and also debug. We are having some issues with the Offline component but are looking into it. Thanks for your advice and pointers.
Glad I could help!
Hi Micheal, In your great list of options, can you pl. help me understand where does Agentry/Syclo, Sybase/Mobilink and SAP Cloud Platform Mobile Services fits. If they are not part of the your list, can you please provide the pros/cons for each of these?
Please excuse the delayed reply, I have been on vacation until just now. Agentry is no longer strategic and we recommend Mobile Development Kit as a replacement. Sybase technology is still part of our platform (i.e. SAP Cloud Platform Mobile Services) under the hood, an example being Mobilink, that is still used as the underlying protocol to sync Offline OData. Hope that clarifies how our current offering relates to our legacy 🙂
Is there a course that you would endorse that teaches how to create a mobile app?
That depends on what you are looking for specifically. Android, iOS, cross-platform, mobile web? You can find our Mobile-related tutorials here: https://developers.sap.com/tutorial-navigator.html?search=mobile
I'm new to coding. I have a Master of Science in Management Information Systems from Lamar University in Beaumont, Texas. I would like to start creating mobile apps that bring in multiple features for users, such as a responsive app. According to your comment I would like to make mobile apps downloadable to all mobile brands. I assume that I should star, t with one major brand, and roll out the app to other brands. Once the app is downloaded, then the user would create an account on the cloud, which requires a database. I would build a team of coders which would include a full stack developer and a database admin With all this in mind, I have to start by learning how to create my first mobile app. Do I need to start with one major platform such as iPhone or Android, and roll out to other brands? My decision would be based on the two largest user groups in the US, which are Boomers and Millenials.
Is there a way to code the app to multiple platforms, and then extend the functionality of each brand as needed?
I am afraid that this appears to be becoming way too broad a question to answer in this context. Best to pick some platform and just get started if you're looking to get your hands dirty, and take it from there.
What are my platform options, and which one should I begin with?
I'm following the information on developing SAPUI5 applications. The first step covered is setting up the environment. I will develop my first app using my own development tools. The computing resources are as follows
hard drive 118Gb + 1 Tb external hard drive
processor intel i5 4300U 1.9 MHz to 2.49 MHz 64-bit
I would like to download all files from this venture onto the external drive, which will be slow for some time until I can purchase a desktop with sufficient resources. I have created four folders on the external:
Program Files (x86)
Is there someone available to discuss the folders essential to setting up my environment?