Hi,

Is there anyone who can provide me with detailed description of what possibilities you have to setup Baan auditing when using a 3-tier workstation setup. How do you configure:

* $BSE/lib/auditdef6.1
* $BSE/audit
* $BSE/tabledef6.1

etc

Information on this topic is awfully scarce in the official documentation and even the Baan Support Knowledge Base does not help much either. :rolleyes:

Here is what i remind from old implementations. It was on 2-tiers implementations but i don't think that it change anything for a 3-tiers implementations (except if you have multiple application servers (never do that if you don't want to become crazy)).

NEVER EDIT the three files you have listed, they must be updated by baan database tools.

Info for Baan ERP (for what i remember it is exactly same in Baan IV, except perhaps menu names)

All that you need is in Tools/Database Management/Database definition and Directories:

- Database Definition you should have only one line for most common implementation. It means that you use only one database. (you can use multiple and put companies or tables on differents databases). You don't need to chaneg anything here for Audit management.

- Tables by database : main session for Audit:
Here you say to baan wich tables you want that baan audit. Normally, the last line is : All other tables, all companies, database 001, no audit. You should have near 100 tables under audit. You have one line per table and you can say if the table is under audit for all companies or not. Don't forget to do a convert to runtime after changes and never delete the last line (if you do so baan will not know how to manage tabels that are not under audit).

- Audit directory :
Say to baan where you want to store audi files:
You should have something like that : /baanERP/bse/audit/#. So baan will replace # by company number.


Audit file are awfull to manage with external software. But Baan provide 4-GL functions to manage Audit. So if you want to use it you have to create a session to use it. You can also use audit for exchange scheme.

Hope it's help you.
Pierre.

Hi Pierre,

Thanks for the info. I think all Baan admins now how terrible Baan audit can be ;)

Anyway, the problem we encountered is indeed when we added a second application server to an existing 2-tier environment. After alot of experimenting and telephone calls to BS (Baan Support), I found out that the following applies:

If auditing is NOT active AND NOT configured on the second app. server:
* edit parameter tables: possible AND
* run bdbpre/bdbpost: possible

If audit is configured but NOT 'active' then the following applies:
* edit parameter tables: NOT possible
* bdbpre/bdbpost: possible

Finally if audit is NOT configured but active then the following applies:
* edit parameter tables: possible
* bdbpre/bdbpost: NOT possible

Hence my confusion :)

Thank you for the info. Another reason to avoid multiple application servers....

Do you have customizations? Do you success to maintain patch level and customization on the two application servers?

Hi Pierre,

This of course depends on how you define your 2nd application server environment. In our case we opt to install the most minimal $BSE stuff possible ($BSE/bin, $BSE/lib etc) and leave all the rest on the 'main' appliction server. The great advantage is then that you only have 1 software 'depot' to maintain. The big disadvantage is of oourse that you put alot of pressure on your network traffic as all objects from $BSE/application must be repeatedly read from the main application server and send to the 2nd app. server.

It seems a good idea. Sure that you need to have a dedicated network line between the two sevr ers and a lot of RAM for shared memory :-).

Yes,

We have plenty of those :-)

Hi All,

I am would like to reviving this thread, because we are considering the option of Multiple Application Servers, to handle our code migrations and production down times.

Can you all please let me know your comments - for/against that option ?

Thanks!

Phrasanth,

Rather than going for multiple application servers, have you considered a cluster solution?

Hi Pat,

can you please elaborate on the cluster solution.

Thanks

--NP

Phrasanth,

If you are looking at mutiple application servers to avoid downtime and to provide fail-over then a cluster scenario with 2 nodes (1 DB server + 1 App server) could be a option. In that case you just have to make sure you do your sizing correctly. If one the nodes goes down - for whatever reason - you can temporary run DB+application on 1 node.

Hi Pat,

we are looking at a situation where we are lots of code migrations, including domains and tables, hence our code migrations are at an average 3-4 hours.

To avoid so much downtime, and scheduling based on our customers, which share the most of the same baan code, but different databases, we are looking for various alternatives.

We got the failover systems on clusters.

But to make the code migrations easier, we are considering a possiblity -

1. make application servers - 1 master(real production) and 1 slave(replica of prod) and both share same databases.

2. switch over with dns entries, from master to slave.

3. do code migrations on master, runtimes etc.

4. switch over with dns entries, from slave to master.

5. copy/tar/untar os - object files etc from master to slave.

The actual downtime to the end users might be just 3-5 mins to shutdown and get the baan up in 2 environments.

But this doesnt reduce our code migrations time.

Do you have more ideas ? :confused:

Name correction - my name is Prashanth, not Phrasanth, you can call me "NP" in short :)

Thanks!

Hi NP (sorry for the spelling mistake!),

I am not sure that I can follow your scenario completely. If you are going to run two application servers on 1 database you will store the all software versions in the one and same database. This you will need to use VRC's to separate them. But I don't see how you will transfer development work to your live VRC on 1 application without impacting the other one. Or am I missing something here?

Hi Pat,

Sorry for the confusion... :confused:

The 2 application servers share the same customer database companies and NOT the tools company.

The VRC/file structures remains the same, replica on both the systems, when the master gets the code migrations, the OS files and the tools table entries are changed.

So after the code migrations are done on the master server and it regains control then the idea is to replicate the OS files and the tools database from master to slave environments.

I dont know if anyone every considered this idea?

We are still investigating the various possibilities to handle the situation... :cool:

HI NP,
Bringing this one back from the dead. Just curious what did you actually end up doing?

We built our Fast Migration Tools and implemented this :)
The VRC/file structures remains the same, replica on both the systems, when the master gets the code migrations, the OS files and the tools table entries are changed.

So after the code migrations are done on the master server and it regains control then the idea is to replicate the OS files and the tools database from master to slave environments.


Gary,

Did you have any specific question?

It's amazing to look back at the thread after 11 years :)

thanks,
nothing specific was just wondering if it was something that went into production or just thinking out loud on a forum :)