Using a common RBS for many customers..


Author
Message
Edhy Rijo
E
StrataFrame VIP (6.4K reputation)StrataFrame VIP (6.4K reputation)StrataFrame VIP (6.4K reputation)StrataFrame VIP (6.4K reputation)StrataFrame VIP (6.4K reputation)StrataFrame VIP (6.4K reputation)StrataFrame VIP (6.4K reputation)StrataFrame VIP (6.4K reputation)StrataFrame VIP (6.4K reputation)
Group: StrataFrame Users
Posts: 2.4K, Visits: 23K
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

Reply
Edhy Rijo
E
StrataFrame VIP (6.4K reputation)StrataFrame VIP (6.4K reputation)StrataFrame VIP (6.4K reputation)StrataFrame VIP (6.4K reputation)StrataFrame VIP (6.4K reputation)StrataFrame VIP (6.4K reputation)StrataFrame VIP (6.4K reputation)StrataFrame VIP (6.4K reputation)StrataFrame VIP (6.4K reputation)
Group: StrataFrame Users
Posts: 2.4K, Visits: 23K
Dustin Taylor (08/12/2008)
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.

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

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

Edhy Rijo

GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...





Similar Topics

Reading This Topic

Login

Explore
Messages
Mentions
Search