how to set "from email"l in party page or some where else?

[edward wang]

Hi Folks,

I need to set " From eamil" like our company's email address. When i approve
an oder, the customer will be notified by out company's email.
I know in the party admin page can add "email address", but do not know
where?
Thank you

Chwang

[Patrick-4]

https://localhost:8443/catalog/control/main

->  catalog  -> stores -> Emails




On Tue, Jun 1, 2010 at 12:33 PM, edward wang <[hidden email]> wrote:

> Hi Folks,
>
> I need to set " From eamil" like our company's email address. When i approve
> an oder, the customer will be notified by out company's email.
> I know in the party admin page can add "email address", but do not know
> where?
> Thank you
>
> Chwang
>

[edward wang]

got it, Thank you very much.

Chwang

On Tue, Jun 1, 2010 at 11:42 AM, Patrick <[hidden email]>wrote:

> https://localhost:8443/catalog/control/main
>
> ->  catalog  -> stores -> Emails
>
>
>
>
> On Tue, Jun 1, 2010 at 12:33 PM, edward wang <[hidden email]> wrote:
> > Hi Folks,
> >
> > I need to set " From eamil" like our company's email address. When i
> approve
> > an oder, the customer will be notified by out company's email.
> > I know in the party admin page can add "email address", but do not know
> > where?
> > Thank you
> >
> > Chwang
> >
>

[Matt Warnock]

I have a number of newbie questions that don't seem to be answered in
the (technical/business) Production Setup Guides.  Perhaps those of you
that have been down this path before can illuminate my way.  Should some
of these be incorporated into a FAQ of some kind, or the Guides?  Or
have I just missed them somewhere?  Or do I just have idiotic questions
that never occur to anyone else?  Anyway, here goes...

For small companies, it is recommended that the existing "demo" data be
modified to set up a running system.  However, it is never spelled out
(that I could see) exactly how this should be done.  As a general rule,
should you change existing demo records (using the demo data ID) to
match your own data, or is it usually better to add new records in the
usual way and link them up, or some combination?  

For example, the "Company" ID obviously needs to be updated in place, as
that particular ID gets special treatment in lots of places.  But should
I follow the demo data method of having one global "admin" (just change
the password), or should I create new separate accounts for each actual
admin (assuming there might be more than one) and grant them global
permissions?  

Some of the demo data has IDs that clearly identify them as demo data.
As a rule, record IDs cannot be changed without re-creating the record.
But many records, for example "parties", once created, cannot be
uncreated. The argument I've seen on this list is that there are too
many possible associated records, though a SQL "DELETE ... CASCADE"
could solve that issue (unless it varies too much by implementation).
So if you start out with the demo users, parties, products, etc, how do
you eliminate the "cruft" afterward?  

Related to that, how do you merge parties that are found to be
duplicates in your data, or that merge in real life? (OK, probably only
party groups merge in real life.)

On another front, I need to import thousands of parties from another
system, and I don't want to retype them all.  I can't (easily) just dump
to postgresql because the OFBiz table structure is very complex, with
names, addresses, phone numbers, customer IDs, and other data in
separate tables (a good thing, but it vastly complicates data import).
Can I call a service to import this data from a CSV or other relatively
common format with a custom-designed data map of some kind?

Same question, part 2: running in parallel with my old system, I may
need to import data again.  Can I import only the NEW data (can ofbiz
check for existence during import) so that data isn't duplicated by
every re-import?

How do you keep a production database (like postgresql) up-to-date with
the OFBiz code changes?  Does it ALL happen automatically every time you
"./ant run", or is there something more needed?  Do/should you EVER have
to do "run-install" or "run-install-seed" again?  What if seed data
changes, like for fixes to geographic data errors?  Does "demo" data
EVER change in any way that would later need to be incorporated into a
production database?

If so, just how much does "run-install" (accidentally or on purpose)
replace on an existing database?  Since "run-install" is the recommended
method for small companies (rather that building from scratch via seed),
it seems like the behavior of "run-install" on an EXISTING production
database (or a clear recommendation/warning to NEVER do such a
crazy/stupid thing) should be well documented.  For example, I know that
running "run-install" on a production database will reset your passwords
to the defaults (which is probably not a good thing on a production
database, and surprises me because I would expect a failed insert rather
than a successful update), but don't know what else might get broken. If
"run-install" should never happen twice, should it check for existing
data (perhaps in "Company") before blindly overwriting production data?

In a similar vein, I know that "clean-data" only works with the Derby
database, by removing the Derby data files at the OS level, not through
the entity engine.  Therefore, it won't clean a production database
(probably a good thing).  Is there (or depending on answers to the
above, should there be) a way to clean demo data (ONLY demo data) from a
production database?

Also, can I have multiple branches of OFBiz running against the same
production database?  For example, maybe my admins or developers (who
have some tolerance for freshly broken code) use trunk, but maybe I want
my data entry people, and the customer-facing web store, to run a more
stable version, like 9.04 or 10.04.  Is this scenario recommended or
advisable?  It seems like this may be a way to run trunk (for at least
some people), but still have another way to make a needed change (short
of the SQL command line) if the trunk code is currently broken. However,
the Setup Guides make it sound like a choice between mutually exclusive
alternatives.

Finally, I read that /hot-deploy is the place for apps that are local in
nature, and can even over-ride existing ofbiz stock code.  Is there a
way to put local mods of the ofbiz framework configs (like the
production cache flags and entity engine configuration) in /hot-deploy
so any changes can 1) be easily diff'ed against stock code, and 2)
managed/excluded as local code that way, rather than using the three-way
SVN merge that BJ described for me earlier?

TIA.  Sorry for the several (hopefully related) questions at once.

--
Matt Warnock <[hidden email]>
RidgeCrest Herbals, Inc.

[BJ Freeman]

data is usually modified and put in separate files and loaded using
run-install-extseed.
this requires setup the files for ext in the ofbiz-component.xml

if you can access the db then
1)add a delegator in the entityengine xml.
user webtools to induce the entity patterns for the new datasource.
once you clean up the entities then you can write code to transfer data
from one datasource to the other.
you can look at the sync system used by pos for example.

my databases are backed up nightly to another drive. I just had a main
disk fry on me. you can schedule your backups.
I would do a backup before attempting do update.
also there is a upgrade page that lays out any changes.
so changes are automatic with a run once scheduled service.

no easy way to remove demo data. Best is to export all you data though
webtools manually clean the data then import it all.
you can make one big file and use
./ant run-install-file

hotdeploy is what I used to add functionality as well as override some
parts of a component. it must have webapp section to it to use this feature.
I have a backup.sh that pulls all my mods out and mirrors them on my
backup drive. I only have to provide the path to where to store them.
the script also copies itself, since it can be used to put the files back.

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


Matt Warnock sent the following on 6/1/2010 4:15 PM:

> I have a number of newbie questions that don't seem to be answered in
> the (technical/business) Production Setup Guides.  Perhaps those of you
> that have been down this path before can illuminate my way.  Should some
> of these be incorporated into a FAQ of some kind, or the Guides?  Or
> have I just missed them somewhere?  Or do I just have idiotic questions
> that never occur to anyone else?  Anyway, here goes...
>
> For small companies, it is recommended that the existing "demo" data be
> modified to set up a running system.  However, it is never spelled out
> (that I could see) exactly how this should be done.  As a general rule,
> should you change existing demo records (using the demo data ID) to
> match your own data, or is it usually better to add new records in the
> usual way and link them up, or some combination?  
>
> For example, the "Company" ID obviously needs to be updated in place, as
> that particular ID gets special treatment in lots of places.  But should
> I follow the demo data method of having one global "admin" (just change
> the password), or should I create new separate accounts for each actual
> admin (assuming there might be more than one) and grant them global
> permissions?  
>
> Some of the demo data has IDs that clearly identify them as demo data.
> As a rule, record IDs cannot be changed without re-creating the record.
> But many records, for example "parties", once created, cannot be
> uncreated. The argument I've seen on this list is that there are too
> many possible associated records, though a SQL "DELETE ... CASCADE"
> could solve that issue (unless it varies too much by implementation).
> So if you start out with the demo users, parties, products, etc, how do
> you eliminate the "cruft" afterward?  
>
> Related to that, how do you merge parties that are found to be
> duplicates in your data, or that merge in real life? (OK, probably only
> party groups merge in real life.)
>
> On another front, I need to import thousands of parties from another
> system, and I don't want to retype them all.  I can't (easily) just dump
> to postgresql because the OFBiz table structure is very complex, with
> names, addresses, phone numbers, customer IDs, and other data in
> separate tables (a good thing, but it vastly complicates data import).
> Can I call a service to import this data from a CSV or other relatively
> common format with a custom-designed data map of some kind?
>
> Same question, part 2: running in parallel with my old system, I may
> need to import data again.  Can I import only the NEW data (can ofbiz
> check for existence during import) so that data isn't duplicated by
> every re-import?
>
> How do you keep a production database (like postgresql) up-to-date with
> the OFBiz code changes?  Does it ALL happen automatically every time you
> "./ant run", or is there something more needed?  Do/should you EVER have
> to do "run-install" or "run-install-seed" again?  What if seed data
> changes, like for fixes to geographic data errors?  Does "demo" data
> EVER change in any way that would later need to be incorporated into a
> production database?
>
> If so, just how much does "run-install" (accidentally or on purpose)
> replace on an existing database?  Since "run-install" is the recommended
> method for small companies (rather that building from scratch via seed),
> it seems like the behavior of "run-install" on an EXISTING production
> database (or a clear recommendation/warning to NEVER do such a
> crazy/stupid thing) should be well documented.  For example, I know that
> running "run-install" on a production database will reset your passwords
> to the defaults (which is probably not a good thing on a production
> database, and surprises me because I would expect a failed insert rather
> than a successful update), but don't know what else might get broken. If
> "run-install" should never happen twice, should it check for existing
> data (perhaps in "Company") before blindly overwriting production data?
>
> In a similar vein, I know that "clean-data" only works with the Derby
> database, by removing the Derby data files at the OS level, not through
> the entity engine.  Therefore, it won't clean a production database
> (probably a good thing).  Is there (or depending on answers to the
> above, should there be) a way to clean demo data (ONLY demo data) from a
> production database?
>
> Also, can I have multiple branches of OFBiz running against the same
> production database?  For example, maybe my admins or developers (who
> have some tolerance for freshly broken code) use trunk, but maybe I want
> my data entry people, and the customer-facing web store, to run a more
> stable version, like 9.04 or 10.04.  Is this scenario recommended or
> advisable?  It seems like this may be a way to run trunk (for at least
> some people), but still have another way to make a needed change (short
> of the SQL command line) if the trunk code is currently broken. However,
> the Setup Guides make it sound like a choice between mutually exclusive
> alternatives.
>
> Finally, I read that /hot-deploy is the place for apps that are local in
> nature, and can even over-ride existing ofbiz stock code.  Is there a
> way to put local mods of the ofbiz framework configs (like the
> production cache flags and entity engine configuration) in /hot-deploy
> so any changes can 1) be easily diff'ed against stock code, and 2)
> managed/excluded as local code that way, rather than using the three-way
> SVN merge that BJ described for me earlier?
>
> TIA.  Sorry for the several (hopefully related) questions at once.
>

[Matt Warnock]

Thanks BJ for some of the answers. But see further questions below.
--
Matt Warnock <[hidden email]>
RidgeCrest Herbals, Inc.

On Tue, 2010-06-01 at 17:39 -0700, BJ Freeman wrote:
> data is usually modified and put in separate files and loaded using
> run-install-extseed.
> this requires setup the files for ext in the ofbiz-component.xml

Edit the demo data using the app screens, and save using some ofbiz
command? or copy/edit the demo-data XML files? Based on what you say
later about run-install-file I assume the latter?

Do you have to configure ofbiz-component.xml separately for all
applications, or is there one central place?

> if you can access the db then
> 1)add a delegator in the entityengine xml.
> user webtools to induce the entity patterns for the new datasource.
> once you clean up the entities then you can write code to transfer data
> from one datasource to the other.
> you can look at the sync system used by pos for example.

Not sure I understand what you are saying here.  I did add the delegator
in entityengine.xml to talk to the postgresql database, so now all data
is persisted there.  It automatically created the data tables, indexes
and so forth needed.  

Or are you saying this is also the way to import the thousands of data
records?  If I define a datasource that is a CSV file, I then write code
to read that file and write to the party manager entities?  I assume
then that the answer to the re-import question is "only if I write it"?
I'll have a look at the POS-sync system.

> my databases are backed up nightly to another drive. I just had a main
> disk fry on me. you can schedule your backups.
> I would do a backup before attempting do update.
> also there is a upgrade page that lays out any changes.
> so changes are automatic with a run once scheduled service.

I backup nightly with pg_dumpall, but I could set up a nightly hot
backup server easily enough, or even a distributed database (hot
real-time slave) using slony or other postgresql tools.

So then there is never any need to run "ant run-install" or "ant
run-install-seed" after that first time?

> no easy way to remove demo data. Best is to export all you data though
> webtools manually clean the data then import it all.
> you can make one big file and use
> ./ant run-install-file

Thanks for that solution, I'll try that out.

> hotdeploy is what I used to add functionality as well as override some
> parts of a component. it must have webapp section to it to use this feature.
> I have a backup.sh that pulls all my mods out and mirrors them on my
> backup drive. I only have to provide the path to where to store them.
> the script also copies itself, since it can be used to put the files back.

So then the framework edits don't work this way, only top-level webapps?
Thanks for the backup script idea, I'll have to do something like that.

> =========================
> 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>
>
>
> Matt Warnock sent the following on 6/1/2010 4:15 PM:
> > I have a number of newbie questions that don't seem to be answered in
> > the (technical/business) Production Setup Guides.  Perhaps those of you
> > that have been down this path before can illuminate my way.  Should some
> > of these be incorporated into a FAQ of some kind, or the Guides?  Or
> > have I just missed them somewhere?  Or do I just have idiotic questions
> > that never occur to anyone else?  Anyway, here goes...
> >
> > For small companies, it is recommended that the existing "demo" data be
> > modified to set up a running system.  However, it is never spelled out
> > (that I could see) exactly how this should be done.  As a general rule,
> > should you change existing demo records (using the demo data ID) to
> > match your own data, or is it usually better to add new records in the
> > usual way and link them up, or some combination?  
> >
> > For example, the "Company" ID obviously needs to be updated in place, as
> > that particular ID gets special treatment in lots of places.  But should
> > I follow the demo data method of having one global "admin" (just change
> > the password), or should I create new separate accounts for each actual
> > admin (assuming there might be more than one) and grant them global
> > permissions?  
> >
> > Some of the demo data has IDs that clearly identify them as demo data.
> > As a rule, record IDs cannot be changed without re-creating the record.
> > But many records, for example "parties", once created, cannot be
> > uncreated. The argument I've seen on this list is that there are too
> > many possible associated records, though a SQL "DELETE ... CASCADE"
> > could solve that issue (unless it varies too much by implementation).
> > So if you start out with the demo users, parties, products, etc, how do
> > you eliminate the "cruft" afterward?  
> >
> > Related to that, how do you merge parties that are found to be
> > duplicates in your data, or that merge in real life? (OK, probably only
> > party groups merge in real life.)
> >
> > On another front, I need to import thousands of parties from another
> > system, and I don't want to retype them all.  I can't (easily) just dump
> > to postgresql because the OFBiz table structure is very complex, with
> > names, addresses, phone numbers, customer IDs, and other data in
> > separate tables (a good thing, but it vastly complicates data import).
> > Can I call a service to import this data from a CSV or other relatively
> > common format with a custom-designed data map of some kind?
> >
> > Same question, part 2: running in parallel with my old system, I may
> > need to import data again.  Can I import only the NEW data (can ofbiz
> > check for existence during import) so that data isn't duplicated by
> > every re-import?
> >
> > How do you keep a production database (like postgresql) up-to-date with
> > the OFBiz code changes?  Does it ALL happen automatically every time you
> > "./ant run", or is there something more needed?  Do/should you EVER have
> > to do "run-install" or "run-install-seed" again?  What if seed data
> > changes, like for fixes to geographic data errors?  Does "demo" data
> > EVER change in any way that would later need to be incorporated into a
> > production database?
> >
> > If so, just how much does "run-install" (accidentally or on purpose)
> > replace on an existing database?  Since "run-install" is the recommended
> > method for small companies (rather that building from scratch via seed),
> > it seems like the behavior of "run-install" on an EXISTING production
> > database (or a clear recommendation/warning to NEVER do such a
> > crazy/stupid thing) should be well documented.  For example, I know that
> > running "run-install" on a production database will reset your passwords
> > to the defaults (which is probably not a good thing on a production
> > database, and surprises me because I would expect a failed insert rather
> > than a successful update), but don't know what else might get broken. If
> > "run-install" should never happen twice, should it check for existing
> > data (perhaps in "Company") before blindly overwriting production data?
> >
> > In a similar vein, I know that "clean-data" only works with the Derby
> > database, by removing the Derby data files at the OS level, not through
> > the entity engine.  Therefore, it won't clean a production database
> > (probably a good thing).  Is there (or depending on answers to the
> > above, should there be) a way to clean demo data (ONLY demo data) from a
> > production database?
> >
> > Also, can I have multiple branches of OFBiz running against the same
> > production database?  For example, maybe my admins or developers (who
> > have some tolerance for freshly broken code) use trunk, but maybe I want
> > my data entry people, and the customer-facing web store, to run a more
> > stable version, like 9.04 or 10.04.  Is this scenario recommended or
> > advisable?  It seems like this may be a way to run trunk (for at least
> > some people), but still have another way to make a needed change (short
> > of the SQL command line) if the trunk code is currently broken. However,
> > the Setup Guides make it sound like a choice between mutually exclusive
> > alternatives.
> >
> > Finally, I read that /hot-deploy is the place for apps that are local in
> > nature, and can even over-ride existing ofbiz stock code.  Is there a
> > way to put local mods of the ofbiz framework configs (like the
> > production cache flags and entity engine configuration) in /hot-deploy
> > so any changes can 1) be easily diff'ed against stock code, and 2)
> > managed/excluded as local code that way, rather than using the three-way
> > SVN merge that BJ described for me earlier?
> >
> > TIA.  Sorry for the several (hopefully related) questions at once.
> >

[Adrian Crum-2]

--- On Tue, 6/1/10, Matt Warnock <[hidden email]> wrote:

> From: Matt Warnock <[hidden email]>
> Subject: Production setup questions
> To: [hidden email]
> Date: Tuesday, June 1, 2010, 4:15 PM
> I have a number of newbie questions
> that don't seem to be answered in
> the (technical/business) Production Setup Guides. 
> Perhaps those of you
> that have been down this path before can illuminate my
> way.  Should some
> of these be incorporated into a FAQ of some kind, or the
> Guides?  Or
> have I just missed them somewhere?  Or do I just have
> idiotic questions
> that never occur to anyone else?  Anyway, here
> goes...
>
> For small companies, it is recommended that the existing
> "demo" data be
> modified to set up a running system.  However, it is
> never spelled out
> (that I could see) exactly how this should be done. 
> As a general rule,
> should you change existing demo records (using the demo
> data ID) to
> match your own data, or is it usually better to add new
> records in the
> usual way and link them up, or some combination? 
>
> For example, the "Company" ID obviously needs to be updated
> in place, as
> that particular ID gets special treatment in lots of
> places.  But should
> I follow the demo data method of having one global "admin"
> (just change
> the password), or should I create new separate accounts for
> each actual
> admin (assuming there might be more than one) and grant
> them global
> permissions? 
>
> Some of the demo data has IDs that clearly identify them as
> demo data.
> As a rule, record IDs cannot be changed without re-creating
> the record.
> But many records, for example "parties", once created,
> cannot be
> uncreated. The argument I've seen on this list is that
> there are too
> many possible associated records, though a SQL "DELETE ...
> CASCADE"
> could solve that issue (unless it varies too much by
> implementation).
> So if you start out with the demo users, parties, products,
> etc, how do
> you eliminate the "cruft" afterward? 
>
> Related to that, how do you merge parties that are found to
> be
> duplicates in your data, or that merge in real life? (OK,
> probably only
> party groups merge in real life.)
>
> On another front, I need to import thousands of parties
> from another
> system, and I don't want to retype them all.  I can't
> (easily) just dump
> to postgresql because the OFBiz table structure is very
> complex, with
> names, addresses, phone numbers, customer IDs, and other
> data in
> separate tables (a good thing, but it vastly complicates
> data import).
> Can I call a service to import this data from a CSV or
> other relatively
> common format with a custom-designed data map of some
> kind?

If the other system uses a database that you can access with a JDBC driver, then you won't need an intermediate file format. Just make entity definitions for the other system and access the data using the delegator. You can then write a service to sync data.

> Same question, part 2: running in parallel with my old
> system, I may
> need to import data again.  Can I import only the NEW
> data (can ofbiz
> check for existence during import) so that data isn't
> duplicated by
> every re-import?
>
> How do you keep a production database (like postgresql)
> up-to-date with
> the OFBiz code changes?  Does it ALL happen
> automatically every time you
> "./ant run", or is there something more needed? 
> Do/should you EVER have
> to do "run-install" or "run-install-seed" again?  What
> if seed data
> changes, like for fixes to geographic data errors? 
> Does "demo" data
> EVER change in any way that would later need to be
> incorporated into a
> production database?
>
> If so, just how much does "run-install" (accidentally or on
> purpose)
> replace on an existing database?  Since "run-install"
> is the recommended
> method for small companies (rather that building from
> scratch via seed),
> it seems like the behavior of "run-install" on an EXISTING
> production
> database (or a clear recommendation/warning to NEVER do
> such a
> crazy/stupid thing) should be well documented.  For
> example, I know that
> running "run-install" on a production database will reset
> your passwords
> to the defaults (which is probably not a good thing on a
> production
> database, and surprises me because I would expect a failed
> insert rather
> than a successful update), but don't know what else might
> get broken. If
> "run-install" should never happen twice, should it check
> for existing
> data (perhaps in "Company") before blindly overwriting
> production data?
>
> In a similar vein, I know that "clean-data" only works with
> the Derby
> database, by removing the Derby data files at the OS level,
> not through
> the entity engine.  Therefore, it won't clean a
> production database
> (probably a good thing).  Is there (or depending on
> answers to the
> above, should there be) a way to clean demo data (ONLY demo
> data) from a
> production database?
>
> Also, can I have multiple branches of OFBiz running against
> the same
> production database?  For example, maybe my admins or
> developers (who
> have some tolerance for freshly broken code) use trunk, but
> maybe I want
> my data entry people, and the customer-facing web store, to
> run a more
> stable version, like 9.04 or 10.04.  Is this scenario
> recommended or
> advisable?  It seems like this may be a way to run
> trunk (for at least
> some people), but still have another way to make a needed
> change (short
> of the SQL command line) if the trunk code is currently
> broken. However,
> the Setup Guides make it sound like a choice between
> mutually exclusive
> alternatives.
>
> Finally, I read that /hot-deploy is the place for apps that
> are local in
> nature, and can even over-ride existing ofbiz stock
> code.  Is there a
> way to put local mods of the ofbiz framework configs (like
> the
> production cache flags and entity engine configuration) in
> /hot-deploy
> so any changes can 1) be easily diff'ed against stock code,
> and 2)
> managed/excluded as local code that way, rather than using
> the three-way
> SVN merge that BJ described for me earlier?

Put your custom code in hot-deploy, then create patches for changing settings. You should also keep your custom code in a local repository. So, the workflow would be:

1. Check out OFBiz from Apache repository.
2. Check out custom code from local repository, place it in hot-deploy.
3. Apply patch for configuration settings. The patch could be kept with the custom code - so that it can be kept under revision control too.

>
> TIA.  Sorry for the several (hopefully related)
> questions at once.
>
> --
> Matt Warnock <[hidden email]>
> RidgeCrest Herbals, Inc.
>
>
>
>

[BJ Freeman]

I have the system on a local desktop. I then zip up the files and upload
them to my server.  I use webmin which then unzips the files on my server.
I do all my edits with tools available here.
but if you have vnc you can use gnome GUI and gedit.
I suggest you use ./ant create-component, using the clients name, then
you can put all your new files in that component.
I copy the demo data files into a hot-deploy component /data. I replace
demo with the clients name.
I then edit the ofbiz-component.xml in the new clients component that
that I copied the data files so that the new files are listed. for
safety sake I also comment out the demo data files in the original
components.

you have to search each component in application and framework /data
folder to find them.

========
Your thinking of importing a data file. This method connects your old db
to ofbiz by creating a new datasource for it. as long as the Db is
accessible on your private network, including you VPN, and there is a
jbc driver for it, you can create the datasource.
you do this by copying the proper Datasource and renaming it then change
the datasorce so it can connect to your other systems db.
then you create new entities from the webtools
you can use the same hot-deploy component that you use for the new
client data.
then you create in the entityengine.xml a new delegator for that datasouce.
you then can use code (java, minilanq) to read, massage the data, and
store either way, in realtime.

========================================
You have webtools for reading in new xml files.
and I don't suggest you use run-install on a production server.
I do this in few steps.
I copy the production system code and dB.
I then do a svn update on the copied system
and work through any gotchas.
if you use hot-deploy to over ride the applications and framework then
any updates you do will not effect your work.
after satisfying myself that everything is covered and only then do I
connect my production db to the new code.
I am a packrat so I archive the old code.

that is about as much as I can support on the mailing list.

       

=========================
BJ Freeman
http://bjfreeman.elance.com
Strategic Power Office with Supplier Automation <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
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>


Matt Warnock sent the following on 6/1/2010 9:25 PM:
> Thanks BJ for some of the answers. But see further questions below.

[Matt Warnock]

Thank you for the more detailed response.  That is very helpful.  
<puts head back into studying code/>
--
Matt Warnock <[hidden email]>
RidgeCrest Herbals, Inc.

On Wed, 2010-06-02 at 00:54 -0700, BJ Freeman wrote:

> I have the system on a local desktop. I then zip up the files and upload
> them to my server.  I use webmin which then unzips the files on my server.
> I do all my edits with tools available here.
> but if you have vnc you can use gnome GUI and gedit.
> I suggest you use ./ant create-component, using the clients name, then
> you can put all your new files in that component.
> I copy the demo data files into a hot-deploy component /data. I replace
> demo with the clients name.
> I then edit the ofbiz-component.xml in the new clients component that
> that I copied the data files so that the new files are listed. for
> safety sake I also comment out the demo data files in the original
> components.
>
> you have to search each component in application and framework /data
> folder to find them.
>
> ========
> Your thinking of importing a data file. This method connects your old db
> to ofbiz by creating a new datasource for it. as long as the Db is
> accessible on your private network, including you VPN, and there is a
> jbc driver for it, you can create the datasource.
> you do this by copying the proper Datasource and renaming it then change
> the datasorce so it can connect to your other systems db.
> then you create new entities from the webtools
> you can use the same hot-deploy component that you use for the new
> client data.
> then you create in the entityengine.xml a new delegator for that datasouce.
> you then can use code (java, minilanq) to read, massage the data, and
> store either way, in realtime.
>
> ========================================
> You have webtools for reading in new xml files.
> and I don't suggest you use run-install on a production server.
> I do this in few steps.
> I copy the production system code and dB.
> I then do a svn update on the copied system
> and work through any gotchas.
> if you use hot-deploy to over ride the applications and framework then
> any updates you do will not effect your work.
> after satisfying myself that everything is covered and only then do I
> connect my production db to the new code.
> I am a packrat so I archive the old code.
>
> that is about as much as I can support on the mailing list.
>
>
>
> =========================
> BJ Freeman
> http://bjfreeman.elance.com
> Strategic Power Office with Supplier Automation <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
> 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>
>
>
> Matt Warnock sent the following on 6/1/2010 9:25 PM:
> > Thanks BJ for some of the answers. But see further questions below.