SITUATION IDENTIFIED IN:
Configuring storage of audit data.
Using a special format for the database definition you can specify that the audit data should be stored on a remote server.
A typical situation would be a configuration existing of one or more Application Servers and a Database Server, containing a centralized location of your storage of your audit data.
The endusers usually log on to Baan via the Application Server. At the Application Server the bshell processes are running, and depending on the way things are configured, the database driver process runs also on the Application Server or on the Database Server.
The Database Server has also a BSE environment installed, so it would be possible to log in Baan via the Database Server as well.
This solution specifies how the format of an entry in the file $BSE/lib/tabledef6.x should to setup remote storage of audit data. (Regarding BaanIV, take notice of Note 2. "Availibility of the format for remote audit setup for BaanIVc")
The generic format of an entry in the $BSE/lib/tabledef6.x at the Application Server is:
<tablename>:<company nr>:<database type>[(parameters)]:<name of remote
And at the Database Server, the file $BSE/lib/tabledef6.x contains the standard format. So for this example:
At the Application Server the 4th column (also the last column) specifies now the name of the remote system. Because it does not contain a "Y" or "N" now, but the name of the remote system, the bshell will replace the name of the remote system for: &<name of remote system>!audit:N (This is according the old format, refer to NOTE 3).
An audit driver will be started at the remote server specified, and therefore the audit data is stored also at the remote server. (According the paths as specified in the file $BSE/lib/auditdef6.x at the remote server). So the tabledef6.x at the remote server is not read in this case.
1) Do not share directories / file system to enable multiple BSE environments to write their audit data to the same location.
The way this solution describes is the correct way of setting up centralized storage of the audit data, to keep the audit data consistent. It is not supported that multiple audit drivers, running at seperate, multiple BSE environments all write to same audit files via a shared directory or file system. This is because information regarding unique audit id's are maintained in shared memory. In that case each BSE environments maintains it own unique audit id's in its own shared memory. In this way it can happen that, when storing audit data, unique id's are messed up. This does not happen when audit data is written only from one BSE environment, like happens when configuring tabledef6.x in the way explaned in this solution.
2) Availibility of the format for remote audit setup for BaanIVc (For iBaanERP this format was already available)
The format, as described in this solution, became at a later stage available for BaanIVc. For BaanIVc this format is supported from portingset 6.1c.07.01 and higher
3) Alternative format of remote audit storage setup.
There is also another format of specifying remote audit storage setup. This format is somewhat more comprehensive to use.
This format is:
<tablename>:<company nr>:<database type>[(parameters)]&<name of remote
Because of a bug, this format did not work on BaanIVc, and resulting in Error 215 (Illegal state). This bug is solved in portingset version 6.1c.07.01 and higher
Using function rdi.audit.hosts() you can test whether the correct remote system is used for storing audit data.
tname = "tdilc301"
company = 100
ret = rdi.audit.hosts( tname, company, audhost )
message( sprintf$( "%d %-18s (ret %d) ", company, audhost, ret ) )
Below is the explanation of the defect solved in porting set 6.1c.07.01.
PROBLEM DESCRIPTION :
Error 215 (Illegal state) on t
(example tdilc301210) in lock_table, when remote audit is setup on application-server
Details: Customer has setup remote auditing on application-server, that all auditing was done centralized on DB-server. Example with table tdilc301210 tabledef6.1 (app-server):
tabledef6.1 (db-server HMBBLUA): tdilc301:210
If they run now a session on application-server which makes a
db.lock.table(ttdilc301) you get this error: Fatal error: Error 215 (Illegal
state) on tdilc101210 in lock_table
When they remove the remote setup (&HMBBCLUA!audit) that auditing works again local on the application-server, everything is fine.
By the way: On both servers is PS 6.1c.06.05 installed. I checked terra, but no issue found regarding to latest PS 6.1c.06.06
SPECIFIC PARAMETER SETUP :
STEPS TO BE FOLLOWED :
To get this easily reproduced I have created a 3GL-script with contents:
and have compiled this as session otdilclocktest at the application-server. So simply running that session there results in the error
OBSERVED RESULT :
remote auditing with db.lock.table does not work
EXPECTED RESULT :
remote auditing with db.lock.table should work.
IMPACT ON CUSTOMERS :
remote auditing with db.lock.table does not work
************END OF SOLUTION *************
We did encounter this error once only. The problem appears to have been resolved in 6.1c.07.01 with changes in tbaledef6.1 .
Hope this helps.