Stupid mistakes might happen: from the newest fresh colleagues who just graduated to the most senior well experienced ones. To be honest, at they needn’t be named “dumb”, but rather “underestimated” or even “distraction”.
Asides from naming them, the most frustrating part, is wasting a huge amount of time, thinking about the most complicated solution to solve your deployment problem… While you forgot to add the proper HTTPS port into your application.
In this article, I would like to share with you, the top 10 stupid mistakes I did in order to not forget them anymore and stop wasting huge amounts of time on little things: before getting into the core of this article, let me introduce myself.
My name is Lorenzo Neri, a Cap4 Lab integration engineer. Several times during my working time, I met many different problems I tried to solve, then afterward, a question came to my mind: “What if I bring help to other people to solve my same problem?”.
№ 1 API deployment: stupid mistakes could cost a lot of time, thank you “complexity bias”
There’s a common human root related to the topic of this article: complexity bias.
To not get way too much-complicated psychology stuff, the complexity bias could be summed up with the following sentence:
Even if your problem is the simplest world’s thing to be solved, you will solve it with over-complicated solutions.
This, happened to me several times during API deployment, spending a lot of time understanding where the error was.
This article aims to share with you my common scenarios and related solutions: let’s start with the first one.
№ 2 VM arguments: are you sure that you set them properly?
Several components inside of your application, require parameters to work in the right way, right?
It happens, that you decided to parametrize them with VM arguments: as soon as you deploy them, you’ll receive back from the application’s log tons of Java stack trace exceptions.
Due to the complex nature of Anypoint Studio and, of course, of your application, it might happen that you forgot some VM argument in the middle of your components.
The best way to handle this issue is to create a configuration file listing all of the VM arguments you need to run locally and deploy your application.
It doesn’t matter if it’s TXT, YAML, etcetera, what really matters is to save it in an unforgettable location to not waste time after.
№ 3 Keystores: did you checklist their own configuration parameters?
As soon as you need to configure an HTTPS listener into your application, well… You need a Keystore to let it work properly.
The first step is to check if you parametrized well into the HTTPS listener configuration the Keystore reference to your application’s folder!
Another crucial point related to key stores is that they need alias, password, and key password.
Several times, these parameters are parametrized in turn.
In a nutshell: check if you have well set them into the configuration files related to the several environments your application is deployed into!
№ 4 HTTP or HTTPS: which one do you HAVE to use before being stuck into deployment?
On several occasions, your final customer won’t allow using an ordinary HTTP connection and even decides to block traffic from the external internet into your VPC.
Therefore, you HAVE to set the right ports for your HTTP(S) listener(s).
In order to deploy your application properly, be sure that is configured with the right references, VM arguments, and, last but least, has the proper references from your VPC (like “https.private.port”)!
№ 5 Ports: does your application need to be reached out from the external internet?
This point is strictly related to the previous one.
If your application needs to be reached out of the external internet, be sure that its own listeners are well configured according to the VPC’s port opened in order to receive traffic from the external internet!
№ 6 Deployment region: does it match your VPC?
Let’s imagine that your VPC is deployed to the EU Frankfurt region.
You’re after deploying your application right now.
You did all, EVERYTHING right: all of the points mentioned too.
But… It does not work, you’re not able to reach it out: what could it be?
Probably, due to the “success fever” you got… You didn’t realize that your application, is deployed to the US Ohio region.
The application’s region and VPC’s region HAVE to match!
To conclude our dumb checklist for API deployment, in this last part of the article we could talk about EAPI, or well written: experience API.
№ 7 Experience API: points that could let you frustrated
Due to their own nature, experience APIs face external internet traffic: you need two main ingredients
The first one is two reserved properties related to the environment you’re currently deploying into.
These reserved properties are:
anypoint.platform.client_id
anypoint.platform.client_secret
The second ingredient is your API autodiscovery ID.
Do not forget to set it properly into your global configuration XML file.
That’s not all: be sure that as soon as you deploy your application that the API Autodiscovery ID becomes unlocked.