1.7. Concept of communication

How is the communication done, what needs to be available. This is an important question to understand the concept of the configuration.

There are three parts involved in it.

BOA Application
iAPI server
Browser client side

BOA Application

This has to be installed on the server your customer will start the application. For this you need to have a working webserver, which can be used for webapplications as Wordpress, Prestashop, ... This server will have an Apache server or Internet Information server installed. Even with several different customers, you can have ONE server installed, which will be used by all your customers. See installation of BOA server for more information.

With one licence of BOA, you can install unlimited BOA servers. If your customer prefers to have it installed on their own server, you can provide the application to them to get installed by their IT team.

iAPI server

This is the server you create in the language of your choice. In this case you don't need to have an Apache or ISS server. The server you build is installed on the customers server. This can be a local server, a local desktop or a cloud server. This can be a Windows system, but can also be any system you like. If you develop an iAPI server on Linus, it doesn't matter.

You will have to install it for every customer on the server that is available. This is the back-end of your system, and needs to have access to the data. See installation of iAPI server for more information.

Browser client side

Any browser on the device your user wants to use, whether it is a Desktop, notebook, tablet or smartphone.

When a user want to connect to the application, he/she enters the URL you provided. This is the URL of your BOA server, or his own server if BOA is installed on it.

Complete configuration scheme sample

BOA 1: BOA Application on main server: boa.mijndomein.com with Apache.
Customer A goes to http://boa.mijndomein.com to start his BOA version. The login screen appears.
After login and password, he enters the URL for his own iAPI server, eg. http://123.100.110.001:8888. Next time he start BOA, this will be presented to him by BOA. There is a cookie set for this. He can work and communicate with his own iAPI server.
Customer B goed to the same URL http://boa.mijndomein.com, the login appears.
After login and password, he enters the URL for his own iAPI which is configured on his own website. So he can enter an easy to remember URL as compta.customerdomain.be:8888. With the cookie he needs to do that only once.
Customer C .... and so on. There is no limit.
BOA 2: A big customer wants this installed on his own server, since it is used by customer to check the availability of products. So BOA is installed on his ISS server and can be reached by

http://B2B.bigcustomerdomein.com. For this customer you can configure the IP address BOA needs to connect to as default URL.
External sales people of this big customer also uses the system. They go to http://B2B.bigcustomerdomein.com and get the login.
In this case the URL won't be asked, since this customer has his own server. Some kind of 'private cloud' server. After login the iAPI decides which menu options may be available.
One of his B2B customers goes to the website of his supplier, and clicks on the B2B link on their website. This starts the http://B2B.bigcustomerdomein.com and the login appears.
After entering his login and password, the iAPI can also decide what the menu options must be, and what to show in the forms.

BOA 3: there is no limit of the number of servers you can install.

With one licence of BOA, you can setup the above scheme without any problem.