is there a good reference to explore about this topic or some training available on Cumulocity website which can be used to build the needed knowledge based on existing and well documented best practices?
now in a single tenant we are interacting with one URL for API calls→ probably in multi-tenant we need a to interact with a different API URL for every tenant
also concerning device management, bulk registration will become per tenant
now we have APAMA microservice connected to Cumulocity microservice via clients or workers, we did not choose to connect this APAMA to this cumulocity tenant, do we need to choose which APAMA connects to which cumulocity tenant in a multi-tenant setup?
That’s how we have our environments set up. We’ve presented a URL based on our domain for each subtenancy, whether Prod or non-Prod. You are correct that you’ll have a different URL for every tenant; we have [product1].bsci.com, [product2].bsci.com, etc. The REST endpoints don’t change so scripting is not too difficult. You’ll want to get a wildcard certificate for SSL so you don’t wind up needing to manage a bunch of individual SSL certs - as that expiration period shortens, you’ll wind up making a lot of work for yourself.
Not sure about APAMA as we don’t use that.
We had some help from Pro Services getting everything set up. That made implementation easier.
It really depends on the use case you want to adapt.
For device connectivity the URL is not so important but the credentials especially the tenantId as part of the username is important.
So you just need to replace tenantId in your credentials not necessarily the URLs. There even common tenant indepdent urls like mqtt.cumulocity.com.
There are multiple ways how you can onboard / connect your devices. You can either connect them to your enterprise tenant and e.g. make them available in subtenant by using data broker, microservice etc. or you can decice that each device should connect to dedicated customer tenants directly.
For microservices if using the SDK you can simply access all tenants the microservice is subscribed to when choosing isolation level MULTI_TENANT (when correctly implemented).
Not sure if I completely understand you apama use case. In generall all services should be deployed to your enterprise tenant and you add them to your subtenants via subscriptions. Depending on how the service is developed either an own instance (dedicated resources) is created per tenant or when multi tenant is supported, the service just gets access to that tenant (sharing same resources).
Can you specify how you send requests from within the apama microservice? If you are using the standard API’s exposed by Apama, the requests should always end up at the correct tenant.
If the requests are using fully qualified tenant/domain name, then you would need to handle it on your own.
The general convention for cumulocity microservices is that the platform url (C8Y_BASEURL) is generic (example: http://cumulocity:8111 or something like that) and microservices will then add the appropriate tenant identifier in auth requests (example: Basic Auth header → tenantId/microservice_service_username:microservice_service_password), this will make sure the requests are always routed to the correct tenant.
to summarize and to answer some questions in the previous replies:
So we can conclude that an on-demand training that we can view on the website about multi-tenancy is not available - Please confirm
Also we can conclude that a multi-tenant documentation in any form like a documentation, whitepaper, Validated design guide etc.. which would summarize the best practices to be followed doesn’t exist - Please confirm
Concerning wildcard certificate SSL (in reply#1) we don’t manage it in the current single tenant why do we need to do it after migrating to multi-tenant setup?
Device management: so when we upload the devices for all tenants in bulk (using CSV) we will need to mention the tenant ID as part of the credentials. Now when we don’t mention any tenant ID, the devices will be added to the main tenant: “{password}@{username}@” so we assume that with the addition of sub-tenant id the formant would become “{password}@{tenantid/username}@“ correct?
concerning APAMA, based on expected BOQ we expect 1 APAMA 1c-8G dedicated for every sub-tenant, do we still need in this case to do the corresponding subscriptions? In single tenant we did not have to subscribe the APAMA microservice to our tenant so it seems it is needed only in case of sub-tenants?
that is how we are currently sending requests from APAMA to cumulocity, does it mean that we are using the standard API exposed by APAMA? and based on #5 do we still need to indicate the tenant ID in the auth header? we dont have auth at the moment between APAMA and C8Y
EPL snippet now
For 5 and 6, no additional changes are required. Since the EPL application is deployed to separate instances of a per-tenant apama microservice, the code will be talking to only the tenant that the microservice is subscribed to.
Ops can just subscribe the dedicated per-tenant microservice to each of the tenants you will be using, this is similar to what you have even in the current scenario where a large per-tenant microservice is subscribed to a single tenant. No action will be required on your side
Thanks Sandeep, this part is clear now
I have created the 3 sub-tenants and waiting for cloud-ops to associate to each one of them an APAMA2c-8g
how can I make sure to follow the multi-tenant best practices? any documentation? recommended trainings?
I only found one training EPL Apps Multi-Tenancy - YouTube
for example when creating the sub-tenants there is something called tenant policy, should I keep it as none? and what about tenant limits? should I keep them blank? and what about “Enable Gainsight product experience tracking“ should I keep it unchecked?
Since in your case, the deployment will be across separate per-tenant isolated instances, your EPL apps isolated by default and should not require any changes. They can be deployed to all tenants individually
Of course, if you have EPL apps that use hard coded values for group/device/managed object ‘id’ , these will be different across tenants, so you should make appropriate changes
we are facing a weird issue in multi-tenant that we never faced in a single tenant: we have an HTML widget which fetches a specific managed object etc.. fetch which is still working normally in single tenant is not working in the new sub-tenant: error 403 forbidden , even though same base 64 password in the widget is the one used in postman and fetch of the MO in postman is working, I even tried the same user/password of the owner of this MO same issue, and I also tried using tenantid/user:password before encoding the base 64, same issue, any suggestions?
I would let some one more knowledgeable about the HTML widget to comment on this.
My best guess is that since you are seeing a 403 error, perhaps the user doesn’t have the correct set of roles assigned to them on the child tenant. Can you check the roles?
