Multi-Tenant Site Properties not available in Service Center

Multi-Tenant Site Properties not available in Service Center

  

Ok, I quit searching it...

Here's the question:

Does Service Center support Multi-Tenant Site Properties from eSpaces with a Single-Tenant User Provider?


The Story:

I have a single-tenant eSpace (ES1), with 3 multi-tenant site-properties. This ES1 has a User-Provider defined other than Users - is using UP1, a single-tenant eSpace used as User Provider.

Now, I want to go to Service Center and access my 3 multi-tenant site-properties, but there's no "Tenants" tab in the eSpace details page (<host>/ServiceCenter/eSpace_Edit.aspx?EspaceId=<the_id>). Usually we see this tab in the Users eSpace.
I tried to search in UP1 (where I expected to see it) and I also tried in ES1.

...no sign of it.

I think this is an issue in Service Center, probably not showing the tab because the User Provider eSpace is single-tenant...

For now, the only way I found to change the properties it's to fetch the Site Properties from the database, querying OSSYS_SITE_PROPERTY and accessing directly the page for Site Property edition, this one: <host>/ServiceCenter/eSpace_SiteProperty_Edit.aspx?SitePropertyId=<the_id>

#sadbuttrue

In the end:

This is really an issue or I'm completely lost and in fact I can access the "Tenants" tab somewhere I'm not wondering?


Thanks for your time.



Best regards,


Hi Ricardo.

I believe the issue is really that the eSpace should be multi-tenant.

Just curious about the use-case you're having to use such an odd scenario?

Hi, 

I can confirm that the property, being marked as Multi-Tenent in an espace that has a Single Tenent Users provider, just disappear. 

I think it shouldn't. As in this case, you will still have a "tenent". 

But in any case, setting those site properties to single tenent will have the same effect it would have in case they didn't disappear.

Cheers,
Eduardo Jauch

Hi Ricardo,

just to ask the obvious... are there any Tenants defined in your environment?

Gonçalo Martins wrote:

I believe the issue is really that the eSpace should be multi-tenant.

I think the same. It is not expected that a single-tenant eSpace is being used as User Provider in a (mainly) multi-tenant environment.

Just curious about the use-case you're having to use such an odd scenario?

It's an infrastructural eSpace with common entities and actions (like demographic info, country related stuff, system settings and so on).

Jorge Martins wrote:

Hi Ricardo,

just to ask the obvious... are there any Tenants defined in your environment?

The obvious answer is Yes. :)


Thanks.

Eduardo Jauch wrote:

But in any case, setting those site properties to single tenent will have the same effect it would have in case they didn't disappear.

Hum...I think I didn't get your point.

Are you telling me to change my Site Properties to be single tenant?
Sorry, but that's not possible - they're needed configurations per tenant.


Best regards,

Ricardo Saraiva wrote:

Eduardo Jauch wrote:

But in any case, setting those site properties to single tenent will have the same effect it would have in case they didn't disappear.

Hum...I think I didn't get your point.

Are you telling me to change my Site Properties to be single tenant?
Sorry, but that's not possible - they're needed configurations per tenant.


Best regards,

Hi :)

No. I'm telling that if the site properties are defined in a single tenent eSpace with a single tenent Users provider, even if they didn't "disappear", you would not be able to configure it by other tenents.

It is just a thought, because I never faced this scenario before, and because the properties become unavailable in this scenario. 

If you need them to be configurable per tenent, you need to move them to a multitenent espace.

Why do you put them in this single tenant module?

Cheers,
Eduardo Jauch


Eduardo Jauch wrote:

If you need them to be configurable per tenent, you need to move them to a multitenent espace.

This answers your question:

You can select per Site Property if it inherits the eSpace configuration or you can explicitly set it.



Best regards,


Hello Ricardo,

Yes. I'm aware you can define a property as "multi-tenent" even if the eSpace is not :)

The problem is that you are using a Users provider that is ALSO single tenent. In this situation, there will be no tenent configuration. Your eSpace site-properties will have access to a single tenent. 

And while I think the "tenent" tab should still be there and you should still be able to configure your multi-tenent site properties in this module, they would have a single tenent to be configured in and other modules that would like to access its value (through public actions) would see all the same value. No multi-tenancy here. And in this case, your site-properties being multi-tenent or not would have the same effect.

Or am I wrong here? 

Cheers,
Eduardo Jauch

EDIT.

This is why I think you need to move your site properties to a eSpace that is multi-tenent (in the sense the Users provider is multi-tenent).

Eduardo Jauch wrote:

The problem is that you are using a Users provider that is ALSO single tenent. In this situation, there will be no tenent configuration. Your eSpace site-properties will have access to a single tenent.

^ This is not correct Jauch. ^

As long as I set a Tenant (using TenantSwitch) I will create the context to access my multi-tenant defined Site Properties.

Also, look at the OSSYS_SITE_PROPERTY table: there's a TENANT_ID that identifies to which tenant that PROPERTY_VALUE belongs to.

And while I think the "tenant" tab should still be there and you should still be able to configure your multi-tenent site properties in this module

Yes, this is the only thing that is annoying me (and the point of this thread) and that I think the Service Center dev. team is not aware. In fact, now I think this post is more like a bug report other anything else. :)

Anyway, thanks a lot for your inputs.
I'm aware of the things you pointed out, but for sure it will help others that may read this post.


Best regards,

Hi Ricardo.

Sorry, you're right. As you are using a different User provider, you can bind the tenant to the user on login using the TenantSwitch. 

The documentation tells us to define the User Provider as multi-tenant to ensure isolation.
Why are you using a single tentant User provider? What do you achieve with this that you don't with a Multi-tenant User Provider (that would solve your problem with the site properties)?

Cheers,
Eduardo Jauch

Eduardo Jauch wrote:

The documentation tells us to define the User Provider as multi-tenant to ensure isolation.

Out of curiosity, where does documentation states that (that we should define the User Provider as multi-tenant)?

I made a quick search in documentation and I haven't found that Users eSpace should be the User Provider.

The closest to that, I found here End-User Management, where we can read:
"The OutSystems Platform provides you with the default Users application to perform end-user management. This application is Multi-tenant ready: when set as User Provider of Multi-tenant applications, it automatically constrains end-users to their tenants."

Nothing says that is should be the User Provider or even that it is a best practice.

Why are you using a single tentant User provider? What do you achieve with this that you don't with a Multi-tenant User Provider (that would solve your problem with the site properties)?

Currently I don't have all the information that lead the person who design it this way to do it so. As far as I understand, the single-tenant eSpace besides being the User Provider, also acts as infrastructural eSpace to hold demographic info, country related stuff, system settings and so on.

Attention that, the fact that the User Provider is single-tenant, we are creating (System).User's (multi-tenant entity) and using the (System).Login action. So, data isolation is kept...

Still, I think the "Tenant" tab being hidden is an hedge case and the Service Center development team should fix it, 'cause so far there are no strong reasons to "oblige" multi-tenant applications to have multi-tenant User Providers...

...I would like to "hear" the 0.50$ from someone from OutSystems.


Best regards,


Ricardo Saraiva wrote:

Eduardo Jauch wrote:

The documentation tells us to define the User Provider as multi-tenant to ensure isolation.

Out of curiosity, where does documentation states that (that we should define the User Provider as multi-tenant)?

I made a quick search in documentation and I haven't found that Users eSpace should be the User Provider.

The closest to that, I found here End-User Management, where we can read:
"The OutSystems Platform provides you with the default Users application to perform end-user management. This application is Multi-tenant ready: when set as User Provider of Multi-tenant applications, it automatically constrains end-users to their tenants."

Nothing says that is should be the User Provider or even that it is a best practice.

From here: https://success.outsystems.com/Support/Enterprise_Customers/Maintenance_and_Operations/How_to_Build_a_Multi-tenant_Application

Setting up the eSpace

To create a Multi-tenant application, every eSpace of the application has to be marked as Multi-tenant.

And From here:

https://www.outsystems.com/help/servicestudio/9.0/Multi-tenant_eSpaces/ImplementingMulti-Tenancy.htm

Implementing Multi-Tenancy

Multi-tenancy allows client organizations to use the same applications through tenants. This way, screens and business logic of applications are shared, though data and end-users are isolated per tenant.

To implement a Multi-tenant application proceed as follows:

  1. Use the Users application as User Provider, the OutSystems Platform automatically constrains end-user per tenant for you.

However, if you are using another User Provider, make sure that it is Multi-tenant to attain isolation of end-users per tenant.

Maybe the documentation is not correct and it's "ok" to use a Single Tenant User provider.There are errors in the documentation, as we know. But after discussing the subject with some colleagues, we believe there is no practical benefit of using a Single Tenant User Provider other than to isolate completely a set of modules from other modules. But this does not seems to be your case. Also, we believe that if you do everything by hand (control of tenants, login, tenant switch, etc) and it works, it's still a lot of work to do something that can be attained much easier using a Multi-tenant User Provider and the standard way of doing things (in this case).

Why are you using a single tentant User provider? What do you achieve with this that you don't with a Multi-tenant User Provider (that would solve your problem with the site properties)?

Currently I don't have all the information that lead the person who design it this way to do it so. As far as I understand, the single-tenant eSpace besides being the User Provider, also acts as infrastructural eSpace to hold demographic info, country related stuff, system settings and so on.

Attention that, the fact that the User Provider is single-tenant, we are creating (System).User's (multi-tenant entity) and using the (System).Login action. So, data isolation is kept...

Not having all the information makes difficult to argue, but I would say that mixing responsibilities (user management/infrastructural stuff) is not the best architecture and shouldn't be done this way. 

In this case, how are you dealing with the rest of the applications that require access to this infrastructure information? Are you using a different Users Provider for them or are you using the same one? 

Usually different Users Providers would mean that your applications would be isolated from each other and to allow you to use the "single tenant" entities and so on, from the infrastructure, if it works, would require a lot of "under the hood" work. 

If you are using the same User Provider (and by what you say I think you aren't), than this doesn't make sense to me. 

In any case, as for what you said, it seems that a normal Multi-tenant User Provider would work perfectly. Doing differently seems to miss the point of all the work the platform does for you. 

In the end, not having all the facts allows me only to think in a "normal" use case scenario.

Still, I think the "Tenant" tab being hidden is an hedge case and the Service Center development team should fix it, 'cause so far there are no strong reasons to "oblige" multi-tenant applications to have multi-tenant User Providers...

...I would like to "hear" the 0.50$ from someone from OutSystems.


Best regards,


I would like to hear from them also. This is an interesting topic.

Cheers,
Eduardo Jauch

Hey Eduardo,


sorry for the late reply.

I'll try to place comments in the most important parts, to do not extend this thread to long.

Related with documentation:

Setting up the eSpace

To create a Multi-tenant application, every eSpace of the application has to be marked as Multi-tenant.

Ok, ^ this is misleading ^ - I may have multi-tenant applications with single-tenant eSpaces (like the Tenant Management eSpace, for instance).

Implementing Multi-Tenancy

(...)

However, if you are using another User Provider, make sure that it is Multi-tenant to attain isolation of end-users per tenant.

Awright! I miss this one!   Still, this sounds more like a best practice, because I may still create single-tenant User Providers just to define different single sign-on contexts.


Imagine the following scenario:

(This is not a real scenario, nor even I'm saying that it's the right way to do it, but we should see it as a possibility.)

I have an OutSystems platform installed and serving multiple customers with their own applications.

Customer Chuck has:

  • App1 - multi-tenant
  • App2 - single-tenant (this is a backoffice for App1)

Customer Norris has:

  • App3 - single-tenant
  • App4 - single-tenant

In order to allow single sign-on for my customer's app, I should create a User Provider for each customer, let's say:

  • Chuck_UserProvider eSpace
  • Norris_UserProvider eSpace

Both are single-tenant and used just to define the single sign-on context (this eSpaces have no entities, screens, actions, or whatever...)

This is possible. (I just tried it again in my personal and it works - no Service Studio warnings. If it's "correct" or not, that's other question.)


Ok, continuing the comments:

(...) I would say that mixing responsibilities (user management/infrastructural stuff) is not the best architecture and shouldn't be done this way.

You're totally right! Mixing responsibilities reveals faulty architecture design.

Are you using a different Users Provider for them or are you using the same one? 

(...) 

If you are using the same User Provider (and by what you say I think you aren't), than this doesn't make sense to me. 

I'm using the same one. And I'm not discussing the sense of it here (however, I think you're also right on it).

This thread is related with the "Tenants" tab not being shown in Service Center in the User Provider eSpace page, when there is this awkward configuration.


Well, in the end, this is an interesting topic and I hope others can also learn from it.   


Cheers pal.

Hi Ricardo,

This is the kind of topic I like, because a simple question can lead to a nice discussion. :)

Yes, here we also use Single Tenant modules in Multi-Tenant applications. The documentations is misleading there.
And yes, here we also use Single Tenant User Provider modules to isolate applications. But in our case, those applications are not Multi-Tenant. 

In your scenario, Norris_UserProvider being Single Tenant seems to not have any impact, as all the Applications the customer uses are also Single Tenant (missing the Tenant tab will not have impact).

But in the case of the Chuck customer, as he is using a Multi-Tenant application (App1), using a Multi-Tenant User Provider is the way to go (in my opinion). And there is no reason to be different, as the isolation and single sign-on will still be there, because you are using different User Providers.

What I didn't understand of the scenario is why App1 is multi-tenant. You want to use this app with other future customers? 

And why the App2 is Single Tenant. Is it a back office for the customer or for the company? In any case, and here I'm speculating because I never used a single tenant module in a multi-tenant application (and didn't tested it), I think it wont matter, as the tenant is bound to the user, not the app/module, and when the user creates data in local entities, the visibility will depend on the entity tenant status (is it single tenant as in the module it is or it is marked as multi-tenant?).

Well, thanks for the discussion. :)
Multi-Tenancy is not wide spread used and I think the reason is exactly because it is not easy to fully grasp its concept. 

Cheers,
Eduardo Jauch


Eduardo Jauch wrote:

What I didn't understand of the scenario is why App1 is multi-tenant. You want to use this app with other future customers? 

And why the App2 is Single Tenant. Is it a back office for the customer or for the company?

Eduardo, check this How to Build a Multi-tenant Application > Managing Tenants and End-Users > Back Office, there's illustrated the scenario we are facing.


Best regards,

Ah!

Ok, the BackOffice for managing the Users/tenants.
Sorry, never remember that. I was fixed thinking in a "Data BackOffice" :D

Cheers,
Eduardo Jauch