02 Naïve Sherpa : Project ConcileTime

Prior Post: https://blogs.sap.com/2019/08/02/01-naive-sherpa-the-journey/

Next Post: https://blogs.sap.com/2019/08/14/03-naive-sherpa-tasking-your-minion/

Why this road?

Before getting into the project we need to take a minute to remind ourselves why we’re on this journey. If you’re still following along, I have to assume that you’re willing to become a SAP PartnerEdge Build partner and put in the development time to create a SaaS offering. You need to be comfortable in your understanding that what you’re trying to accomplish will pay off monetarily in the end. After all this is the goal unless you’re just trying to learn new technology stuff and someone is paying you to do so. You want SAP to opens doors with it’s 437,00 business and public customers so that you won’t have to spend the time and money needed to go after them yourself. SAP want’s to be sure its reputation with the customer is enhanced by bringing in your solution along with the other things SAP is selling. For SAP this may be as simple as you being a good monthly subscriber to its cloud services, or it can be as complicated as bundling your offering with other things, or even giving up a slice of your revenues in exchange for deferring your costs. This is just the reality of the marketplace and it’s good to keep this in the back of your mind.

Secret Sauce.

You have a great idea. Everyone has a great idea. What makes a difference is who can make it real in a timely way in order to make a business out of it. If you look over SAP’s portfolio of platform and industry product offerings, it’s clear that SAP has it’s fingers in a lot of pies. Now you can watch the technology news, and read what SAP puts out in it’s marketing materials, and roadmaps(and I highly recommend that you do), and dutifully absorb every analyst briefing you can find out there but you have to keep something in mind. SAP has 90,000+ employees worldwide and it comes from a software development heritage. There is always someone(and often multiple teams) working on the latest features of various products and you can expect that the features our competitors products that we don’t have yet will also be developed sooner or later. Yes SAP is a large ship that doesn’t turn on a dime, but you can use that as an advantage to your effort if you understand how to work with the constraints. What you do(or should) have is some very in depth domain knowledge. I’m not talking “read a book on the topic” domain knowledge, I’m talking about “years in the business” domain knowledge. If you don’t, then I suggest you find someone who does and team up with them. Pure technical skill and craft will only take you so far and can be learned by anyone with the gumption to sit down and put in the due diligence. When you add machine learning to the mix is when things get even more murky. How do you know when your algorithm has reached “good enough” accuracy and/or repeatability? Having deep domain knowledge will answer this question and more importantly get you closer to the right question(and the right data). This is your offering’s “secret sauce” that your customers need to be willing to pay for. You need to be able to embed it into your offering and sell it easily to your prospective customers without a lot of friction. Sure you can be first to market, or have a huge advertising budget, but these are limited advantages. You need to be valuable and constantly improving because as soon as you show that your idea is worth something, others will try and enter your market(maybe even SAP itself) and they will have the advantage of knowing it’s already worth going after. Patents can help ward off the competition, but can be costly to defend. Make your secret sauce and be the easiest way to get it to your potential customers.

The Project.

As I promised in the last post, I’ll get into explaining some of the detail of the accompanying project. I’m not going to get into all the details as it would be boring and tedious, but I would like to go over the motivation and the structure so that you can look at it and not be intimidated. The goal is to have a working end-to-end example of code that you can refactor into a skeleton project for your efforts. It’s nice to start with something that’s working and then notice when it breaks rather than cut and paste chunks of examples from tutorials and docs that inevitably leave out some crucial step or semi-colon.

I’m building the project as a Multi-Target Application(MTA) following the Cloud Application Programming(CAP) methodology. MTAs follows a micro-service based development paradigm that espouses the 12 Factor App approach. I suggest you read, really read the content in the links of the prior sentence. You need to have these concepts solid in your mind so that you understand what you’re looking at and don’t thrash around in the code aimlessly. Don’t get impatient and start cut/pasting from StackOverflow without understanding what you’re after(and the context the StackOverflow snippet came from) before adapting it to your code.

Now I’m going to take you down a short side trail.

Domain name and SSL Cert.

While you can put off getting a real domain name, I recommend that you don’t. Your offering’s domain name says a lot about what it is and a misleading or cumbersome domain name will lead to customer confusion and missed sales. You’d be surprised how embedded it gets into all your application code and documents and marketing materials. Having to go back and change it is a royal pain. If you haven’t got this figured out, stop now and go to a domain registrar and start searching. You’ll quickly find that all the good names have been taken and that you may have to pick a less than desirable top-level domain(com,net,org,us,biz) in order to get what you want. Sure you can pick something really long or with some tricky spelling to secure your place on the net, but think about how it will look on marketing materials, trying to tell your parents about it, or spell it to a non-native speaker over the phone and you’ll get what I mean. Try to avoid things that are just way too abstract as well or you’ll find the first thing you have to do when trying to sell your offering is to un-explain it(not a good first impression). I use GoDaddy.com but you don’t have to. The domain name I’m using is conciletime as in a play on the words (re)concile your time. Not too long or too hard to spell or say and still a bit witty(comments below for your critique).

We’ll be building our application on SAP’s CloudPlatform(more on this later) which requires a HTTPS connection(HTTP isn’t allowed) so you’ll need to purchase a wildcard SSL for your domain as well. Why wildcard? They’re so expensive! Yes, there is no getting around this unless you want to create your own custom Certificate Authority(CA) but that will require that you distribute your custom CA certs and have anyone who wants to use(or just view) your site to install and trust them. Some IT departments completely prohibit this. Like the domain name issue above, it’s just better to use the real deal from the start. You can always password protect your site if you don’t want prying eye before you’re ready. I shopped around and got one for around $90 from an outfit called Comodo.

I’ve put together a blog post on this with all the gory details.

Step-By-Step Guide to Custom Domains with Multitenant Multi-Target Applications

OK, back to the main trail.

The conciletime project will be hosted on GitHub at https://github.com/alundesap/conciletime.

I’ll try to keep the README up to date as I can but the main structure is like so.

It’s an MTA so the mta.yaml file contains all the detail of how the modules are related. The web module is the “app-router” and serves all static content. While I’ll be deploying this project to Cloud Foundry while trying to make it easily deployed to a HANA XSA system on-premise. Since there are slight differences when deploying each way, I’ve for now included an mta extension descriptor file called mta_to_cf.mtaext that is included in the deploy and overrides certain settings. As such it’s important to look at both files to get an idea what the merged settings will be.

Other files at the root of the project are mostly so various IDEs won’t complain or are part of continuous integration. I’ll get into that later. For now let’s look a the main folders. MTA involved folders are called modules, so if I switch between folder to module, then I’m referring to code in a folder that will create an executable code unit.

app: This is were I expect the main application logic to reside. It’s behind the router so it’s functions will require authentication. Not much here at the moment but stub NodeJS code and some unit testing framework stuff.

db: This is a run and done module that defines your data schema and creates an HDI container for you. The CAP methodology will do some pre-processing of files here and create a gen folder with the actual used files. More on this later as well.

domain: These are files that I wanted to save that pertained to the registry of the domain name and SSL creation. I wanted to save the actual file so that you could compare them to yours if needed.

files: Just as named, these are files that somehow support the project but aren’t critical to it’s building and/or deploying. One file of note is a sample XLS files that you can use as a skeleton for you own project cost projections.

srv: In CAP methodology, this is where the service that exposes your data model(defined in db) as ODATA v4 RESTful endpoints. You shouldn’t have to change much here unless you want to customize how the ODATA works.

tools: This is a folder of Linux BASH scripts that are helpful during development and/or deployment.

util: This module contains code supporting the Multitenant subscribe/unsubscribe functions and other utility features.

web: The main application app-router which should be the entry point of all requests to the application. This module takes care of serving static content(unauthorized) and authorizing and routing requests to other modules in the appliation(namely app and srv).

When working out the issues of making the app Multitenant capable, I had to add a bit of supporting logic that’s detailed in the post above and illustrated in the code. While it might seem overkill at this juncture, I want the app to have these capabilities so that customers purchasing my service can have their own segregated data and manage their own users without having to modify the application for each customer. That’s what’s a good multitenant app does. More details from my colleague Philip can be found here.

That should get you going. In the next blog post, I’ll talk about why it’s important to set up Continuous Integration/Continuous Delivery at the start of your project, even it you’re just working on it alone for now.

Until then…

-Andrew (Your Naïve Sherpa)

GitHub Project:

https://github.com/alundesap/conciletime

https://github.com/alundesap/conciletime/tree/post02

Prior Posts:

https://blogs.sap.com/2019/07/22/00-naive-sherpa-meet-the-naive-sherpa/

https://blogs.sap.com/2019/08/02/01-naive-sherpa-the-journey/

Next Post: https://blogs.sap.com/2019/08/14/03-naive-sherpa-tasking-your-minion/