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).