Need Information - Multi-Tenant Setup

[Former Member]

Hello All,

We have installed Sourcing 7.0 and are looking to do a multi-tenant setup. However there is not much documentation available around the same and hence seeking help from Sourcing Experts in this forum.

As per my understanding till now, each Tenant has to be setup as an independent Enterprise Context in the system. We will then have to create seperate clusters and directory configurations for each of these contexts. Here are my questions regarding the same:

1. Are the system and enterprise user, context independent?

2. Each Cluster has to have a unique hostname. Now this is a issue if we want to run multiple tentnats on a FAT server. Is there any way we can have multiple clusters in same host?

2a. If there is no option but to use a different host, I would like to know if on this host we again need to do a fresh Install of CE 7.1 OR we should create a Add-In instance for CE 7.1?

2b. Also do we need to deploy sourcing application again as per the installation guide on this new add-in/new instance?

3. We are using NetWeaver UME for User Authentication instead of LDAP. I also understand that the users are created and validated against directory configurations. So where is the password stored? I think its in the directory configuration as the generated password during user creation does not align with the NW UME Password Policy. Any ideas here

4. How is the data segregated between different tenant at DB Level? Does the system create a seperate Schema for Every Tenant?

5. Are there any tables in the database that are context indpendent. I am asking this becuase there are few tables where we provide either the context ID or directory configuration ID. For ex- Company. If someone can provide a list of all contenxt independent tables that will help

6. Is there is a possibility of installing 2 instances (DEV and QAS) of sourcing on the same box - ofcourse on different folders. If yes how this can be done

Any help will be appreciated.

Regards,

Shubham

[Former Member]

Hi Shubham

Following are some inputs based on my experience with multi tenancy:

1. Enterprise user depends on context. password you givewhile defining enterprise context is the password for enterprise user.

2. Host name has to be different for each tenant. I don't think it is possible to have multiple clusters/ contexts with same hostname. In case you decide to go for a fresh installation according to installation guide, it can not be classified as multi tenancy since database would be different

3. User password is stored in directory only for authentication purpose along with name, first name, last name, and userID

4. Seperate database schema is allocated to every tenant if you have not defined anty parent child relationship between company contexts

5. Two instances can be applied on the same box creating seperate context/cluster for each with different host name.

Hope this helps

Regards

Mudit Saini

[Former Member]

Hi Mudit,

Thanks a ton for your answers. Just want one more clarification.

If I want to create 6 tenants, I need to have 6 physical/virtual servers with different hostname?

If seperate database schema is created for each context, where does the common objects get stored?

Also if you can explain what do you mean by - "Two instances can be applied on the same box creating seperate context/cluster for each with different host name" - that will be really helpful

Regards,

Shubham

[Former Member]

Hi Shubham

What we had done is we have mentioned different hostnamefor the same IP address (application server) is host file and this worked fine for us. For e.g. lets say your app server IP is 172.17.234.56. In our local system we maintained to host name lets say ESOAPP1 and ESOAPP2 both pointing to the same server IP. these entries we maintained in the local host files. I would suggest discussing the same with your BASIS consultant.

By "Two instances can be applied on the same box creating seperate context/cluster for each with different host name" what I mean is creating two Context/Cluster combination with each cluster having different host name defined. One Context/CLuster combination you can use as QA system and other as PROD.

PS data set for both the systems would be completely different each haveing its own set of enterprise, company, master data etc. User authentication would depend upon the directory config.

Hope this helps!

Regards

Mudit Saini

[Former Member]

Thanks a lot Mudit. Infact I was thinking on the same lines to use the host file to define 2 host names.

Another question is that what is the significance of the Cluster Member and the "Service" that we define in the context. Can it be same for multiple contexts?

Regards,

Shubham

[vikram_shanmugasundaram]

Hi Shubham,

Creating multiple enterprise contexts is a critical design decision that is made at a very early stage of an implementation as that will impact several design decisions made downstream. Typically a multi tenant setup is used when you data needs to be completely segregated, for example, customer 1 on tenant1 and customer2 on tenant2, etc. where customer 1 and 2 are not related. Tenant1 will have its own master data and is not shared with tenant2 and vise versa. Once multiple enterprise contexts are created and data is loaded, it will be messy if you decide to undo the changes.

In the past Iu2019ve seen customers taking the multi-tenant approach so they could have sandbox in tenant1 and dev and tentant2. This approach has many disadvantages is generally a bad idea in my opinion. In your implementation there may be a need for a multi tenant approach, but I just wanted to point these out so a correct decision is made.

To your question regarding DB schema, note, the data for all the tenants reside in the same schema. For example, RFx from tenant1 and 2 will reside in the same DB table in the schema. Each tenant is assigned a context id which determines under which tentant the RFx is created under.

Hope this helps.

Regards,

Vikram

[Former Member]

Thanks Vikram.

Currently I am trying to explore the Multi-Tenant feature and strenghting my concepts around the same. Here is my understanding based on the documentation and the reply I got from you and Mudit:

1. Enterprise Context should be created for an Organization. If there are multiple companies, we should use the company feature. However if the individual company is really huge with different master data we should create them as Sub Context.

2. Typically its advisable to use a seperate cluster for each Context. This means that each orgnization will get a seperate host dedicated to them. Also we can create a seperate cluster for supplier and buyers for better load sharing in case of large installations

3. The buyers are created in Internal Directory Configurations and Suppliers in External Directory Configuration. Each Directory Configuration is associated to one cluster only.

4. Since the user created for a tenant also get created in NW UME, we should use some prefix suffix in the username to clearly distinguish users of two Contexts/Organizations in a Multi-Tenant Setup

If you can validate the above that will be of great help to me and hopefully others who might want to explore Multi-Tenant setup.

Thanks once again for your help.

Regards,

Shubham

[Former Member]

Hi Shubham

I agree with most of the points you mentioned except for seperate clusters for buyers and suppliers. Like you said you can have seperate clusters for companies in case individual company is really huge or you want data segregation/ restrictive access to data but I think it is not possible to have a seperate cluster defined exclusively for suppliers.

Rest looks good to me.I think Vikram can give more insight on the same.

Regards

Mudit Saini

Edited by: Mudit_UCB on Jul 29, 2011 9:02 AM

[Former Member]

Hi Vikram,

Thanks for this information. I have a few questions more on this:

1. Can both the clusters point to the same LDAP for their directories for internal and external users?

2. If we set up two clusters for two different companies of the same organization for transactional data segregation, and if the two companies still share the same ECC, would we have any issues with the integration set up?

3. If the companies were to in future decide on allowing visibility to each other's data, what are the options we have to allow the same?

4. Would the suppliers of the two companies now have to use two different URLs to participate in RFx with the two companies?

4. Are there any other considerations / guidelines to decide whether to go with multiple tenants or not?

Appreciate your inputs as always.

Thanks & Regards,

Subhasini