Hi,

I am working on a project which will be used by many Customers and these may have many branch offices, I am working on having one SQL2005 database for everybody, but of course the end users will only be able to see data from their Customer ID and Branch Office ID.

When login to the application I need to capture the Customer ID and Branch Office ID in the Login form, but how to filter the RBS data per Customer ID and Branch Office ID, so when the managers of one office creates an user and assign roles will only be able to do so for their records?

What would be the best approach to handle this with SF RBS?

Thanks!

Edhy Rijo

We have a need for this as well, and the way we are doing it is to keep each set of customer data in a seperate database alltogether, each with it's own set of security tables.

However, even if you want to keep all customer data in the same database, you will still want to keep seperate security databases for each user, and dynamically specify the securitydatasourcekey depending on their Customer # + Branch Office ID combination. You would need one security database for each user, but that would give you the flexibility you need while still keeping your live data in the same database .

Is this approach a local database at each Customer server? (assumming they have a server :hehe or in your own server you have one database per customer?

Do you mean if I have 200+ Customers, I would need 200+ security databases? that does not make sense, that would be hardly impossible to manage.

Basically all I need to is to control each customer License or Access to the database, also for managing purpose I would like to host all data at my hosting server, but I would not get into creating one database per customer at my hosting.  Any other ideas?

Edhy Rijo

Each customer would have their own database on our server. Yes 200 customers means 200 databases.  We currently use the same methodology to handle multiple instances on the same site and maintenance actually hasn't proven to be an issue in those scenarios. If we need direct access to a given user's data to solve a problem, it is actually simpler since you are only dealing with one user's data at a time. "Maintenance" by way of structure updates and the like is completely automated through our use of the DDT in our installation.  

If that doesn't fit your needs, however, the other option is to extend the vanilla RBS to include your customer number and branch office within the SFSUsers table and BO. You would then need to extend the SFSUsers BO fill methods to only bring in user records for the currently active customer and branch office.

Humm, very interesting, so you won't do the maintenance of structure yourself, it will be a responsibility of an update to be run from the customer application using DDT.

If I go this way and modify the SFSUsers table, will this be break by any future SF update?

Edhy Rijo

Oh no, we don't give the users a full blown version of the DDT. Just thinking about doing that gives me chills . When I said we use the DDT to handle structure updates, I meant we use a DDT package, and deploy that package within our normal installation and update. It's all fairly transparent to the user (they hit "Next" and it does its thing.)



Obviously, if the data were being housed on our servers, the customer wouldn't be updating anything since we would be loading any updates ourselves.



And yep, if you change the RBS source, then you effectively put yourself on an island. Meaning that if you want to load a future update, you'll have to go back and re-do your changes afterwards.

Edhy,

What about making a related table to SFSUsers which holds information on Branch and Customer. Relate it one-to-one to SFSUsers primary key. Make a form in your application to maintain these data, then you are clear of future SF updates.

/Teddy

Thanks Teddy,

That may work, even though still I would need to modify the security form, so when Customer X creates users, my related table would be updated with the Customer ID and Branch ID info, or at least just the Customer ID.

Edhy Rijo