« Quay về OFBIz Tenant for SaaS Cloud computing

Sinh Tenant không cần stop/start lại OFBIz

Luồng thảo luận [ Trước | Tiếp theo ]
Sinh Tenant không cần stop/start lại OFBIz
Câu trả lời
14:51 26/11/2012
-       Chưa tạo và load được tenant ở thời điểm runtime : Có khả năng dùng lệnh để sinh ra tenant không phải khởi động lại máy chủ OFBiz

The advantage with multi-tenant is that the tenant doesn't need access to load data using something like "ant run-install ..." or anything else on the command line. You could have hundreds of people active in other tenant instances so you don't want to stop and start the server to do anything like this, and hopefully you can avoid having an admin work with the tenant to get custom data loaded. You want things to be self-service, and that is the point of making it database driven (with a UI so the user can get stuff into the relevant portions of the database).

In a production environment you don't want to stop the server(s) in order 
to get another tenant instantiated. 
We have solved this by using a separate instantiation of the code as an 
administration client to do the tenant creation and the custom data loading 
for that client.
On Apr 16, 2010, at 5:09 PM, BJ Freeman wrote:
> somehow I did not get marcs reply to so this is to both.
> you say put the data in a db. is this manual or loadable by the reader.
> that is the crux,right now of my focus.
> I imagine at some point the default will have choices using the config
> that hans or I have done.
> some way of creating the installs.
> but for now like most systems , till that is implemented we still have
> to load the tenant data.
> which brings me back to the mechanism to do that
> it is not some much if it is intial-seed, seed, or ext.
> it is how to load the tenant from a command line.
> I have not brought up how to load while one instance is running.
> I am depeding on clustering and be able to use one of the clusters to
> shut down and load. So that is similar to your suggestion of using a
> seperate server. This includes a lock on the tenant so the database is
> not being used during the update.
> this of course would not be done by the tenant. but the SAS provider.
> the other things you bring up are beyond the simple focus of the
> mechanism of loading data, currently, but good to keep in mind.
> =========================
> BJ Freeman
> http://bjfreeman.elance.com
> Strategic Power Office with Supplier Automation <http://www.businessesnetwork.com/automation/viewforum.php?f=93>
> Specialtymarket.com <http://www.specialtymarket.com/>
> Systems Integrator-- Glad to Assist
> Chat  Y! messenger: bjfr33man
> Linkedin
> <http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro>
> David E Jones sent the following on 4/16/2010 2:21 PM:
>> Thanks Marc, this is a good way of looking at it. If you have files know about tenants
then you're really opening a pandora's box and it's much better to have all of the per-tenant
settings sourced through the database.
>> I guess we could have a table in the tenant database that goes along with the Tenant
entity's table that has information about additional data to load.
>> However, given the general use patterns for multi-tenant stuff wouldn't you want
to load the same basic data for each tenant and then let the tenant do the rest, including
loading any data files they might want (probably through an upload or referring to another
>> -David
>> On Apr 16, 2010, at 4:15 PM, Marc Morin wrote:
>>> we've deployed a multi-tenant ofbiz system (our own multi-tenant implementation).
 Our case is simpler, since it is truly a single application with multiple customers, each
in their own database (delegator).
>>> When faced with wanting to read different files for different tenants, we've
generally, moved to storing the per-tenant information in their database instance.  This keeps
management of the per-tenant information separate for the more static "code".
>>> This has meant, re-factoring the code/screens/forms, etc... putting them in "content"
vs files.
>>> As for your example of having "seed" data being tenant aware, this appears to
expose a new more complex problem of managing the life cycle of the tenant (creating, seeding,
terminating, evicting...) that needs to be done to truly make use of any multi-tenant capabilities.
>>> We're taking the approach of creating "data packages" and allowing tenants to
"subscribe" to them.  This then formalizes the management of the "seed" data, it's life cycle,
and ultimately, it's storage.
>>> Now, if you wanted to have a multi-tenant ofbiz, where each tenant has 100% flexibility
on configuring their entities, services, screens, eca, .... then I think you'll need to provision
a separate app server for each...
>>> ----- "BJ Freeman" <bjfree@free-man.net> wrote:
>>>> rephrase this.
>>>> for SAS purposes there will be many files each tenant that are unique
>>>> to
>>>> that tenant and to be loaded only into that Tenants DB
>>>> this requires entry into the ofbiz-component.xml.
>>>> A change in the way the readers select files based on delegator is
>>>> what
>>>> I am suggesting:
>>>> so the command line that has  readers=seed,ext delegator=Tenant1
>>>> would look for files in the ofbiz-component.xml
>>>>   <entity-resource type="data" reader-name="seed-initial"
>>>> loader="main" delegator="Tentant1"
>>>> "location="data/tenant1seedinitialData.xml"/>
>>>> so added parm of delegator would further define the data selection.
>>>> if a line did not include the delegator then default would be used.
>>>> The above suggestion seems to follow the model setup for Multitenancy
>>>> support.

Hỏi đáp PL

Hỏi đáp PL

Câu hỏi Trả lời Người hỏi
Tôi là ai? Mày chẳng là ai cả? dsn
1 2 3
$fields.get("cau_hoi").getValue() $fields.get("tra_loi").getValue() $fields.get("nguoi_hoi").getValue()
$fields.get("cau_hoi").getValue() $fields.get("tra_loi").getValue() $fields.get("nguoi_hoi").getValue()

Các hoạt động

tháng chín 11
Trí Võ viết một đoạn tin trên bảng trạng thái, {3}.
tháng mười một 5
Chúc Hà đã trả lời cho RE: Xây dựng site http://thuphongtrien.com trên nền Liferay 6.1.2 đoạn tin trên bảng trạng thái, {3}.
tháng năm 28
Trí Võ đăng tải một tài liệu mới, ptech.png.
Trí Võ đăng tải một tài liệu mới, Pikon.png.
tháng ba 17
Trí Võ viết một đoạn tin trên bảng trạng thái, {3}.
Đăng ký theo dõi tới các hoạt động của vZik. Mở trên cửa sổ mới