Archiving and Purging the BizTalk Tracking Database

As BizTalk Server processes more and more data on your system, the BizTalk Tracking (BizTalkDTADb) database continues to grow in size. Unchecked growth decreases system performance and may generate errors in the Tracking Data Decode Service (TDDS). In addition to general tracking data, tracked messages can also accumulate in the MessageBox database, causing poor disk performance.

While previous versions of BizTalk Server included sample scripts for archiving tracked messages and purging the BizTalk Tracking database, BizTalk Server automates both processes using the DTA Purge and Archive job. By archiving and purging data from the BizTalk Tracking database, you can maintain a healthy system, as well as keep your tracking data archived for future use. Because BizTalk Tracking database archives accumulate over time and consume disk space, it is a good idea to move the BizTalk Tracking database archives to secondary storage on a regular basis.

When you purge data from the BizTalk Tracking database, the DTA Purge and Archive job purges different types of tracking information such as message and service instance information, orchestration event information, and rules engine tracking data.

The age of a tracking data record is based on the time the tracking data was inserted into the BizTalk Tracking database. The DTA Purge and Archive job uses the time stamp to continuously verify whether the record is older than the live window of data. After every live window period, the BizTalk Tracking database is archived and a new archive file is created. At each SQL Server Agent job interval specified by the job schedule, all completed tracking data older than the live window period is purged.

BizTalk Server uses the concept of a soft purge and a hard purge. The soft purge is used to purge completed instances, while the hard purge is only used to purge incomplete instances.

Soft purge

In the DTA Archive and Purge job, the sum of the LiveHours and LiveDays parameters is the live window of data you want to maintain in your BizTalk Server environment. All data associated with a completed instance older than this live window of data is purged. By default, the DTA Archive and Purge job is not enabled. You must first configure and then enable the job.

For example, you can configure the DTA Purge and Archive job to run every 20 minutes, and set LiveHours=1 and LiveDays=0. The first time this SQL Server Agent job runs (T0), it takes a backup of the tracking database by creating an archive and an entry is saved in the database with this timestamp. A successful archive is necessary in order to purge tracking data. If the archive was successful, then all the data associated with the instances that completed over an hour ago is purged. Each time the job runs, completed data over one hour old is purged. On the 3rd run (after one hour), a new archive is created that contains the data for all instances that were inserted into the tracking database in the last one hour segment.

Here is how you would configure the Archive and Purge step in the DTA Purge and Archive job to match the example above:

exec dtasp_BackupAndPurgeTrackingDatabase
1, --@nLiveHours 1, 
0, --@nLiveDays 
1, --@nHardDeleteDays 
‘\\server\backup’, --@nvcFolder 
null, --@nvcValidatingServer 
0 --@fForceBackup Soft purge process

The time stamp of the last backup is stored in the BizTalk Tracking database and ensures that data is only purged if it is in the previous archive. For additional reliability, archives are overlapped by approximately 10 minutes. The following figure, based on the example above, shows the soft purge process. Note that the archiving and purging tasks do not necessarily happen at the same time.

Soft purge process

Hard purge

Because the soft purge only purges data associated with completed instances, if you have many looping instances that run indefinitely, then your tracking database would grow and these instances would never be purged. The hard purge date allows all information older than the specified interval to be purged except for information indicating a service's existence. You set the hard purge using the @nHardDeleteDays parameter in the Archive and Purge step in the DTA Archive and Purge job. The hard purge setting should always be greater than your soft purge setting. In other words, @nHardDeleteDays should be greater than the sum of @nLiveHours and @nLiveDays.

Archiving and purging includes the features described in the following table:

 

Feature	Description
Hard purge	Enables you to configure a time interval to purge information for incomplete instances older than a specified date.
Copying tracked messages to tracking database	Using the CopyTrackedMessageToDTA option, you can directly copy tracked messages from the MessageBox servers to your BizTalk Tracking database. This is required in order to purge data using the DTA Purge and Archive job.
Archive validation	Enables you to optionally set up a secondary database server to validate the archives as they are created.
Tracking support for multiple BizTalk Tracking database versions	Enables you to use tracking support with BizTalk Server 2004 and BizTalk Server 2006 database archives.
Reduction of tracking data	Substantially reduces the amount of tracking data stored without reducing any tracking information generated. This results in slower growth of the tracking database.
Faster tracking operations, significant optimization in database schemas	Enables you to use tracking tasks for finding messages and service instances on large databases; this feature has been significantly optimized.

Note
If you are having performance issues that are momentarily addressed by purging the BizTalk tracking database, and you want to configure BizTalk to no longer collect tracking information, you may want to consider turning off global tracking. For information about turning off global tracking, see How to Turn Off Global Tracking.

Configure the DTA Purge and Archive Job

How to Configure the DTA Purge and Archive Job

This topic has not yet been rated - Rate this topic

Before you can archive or purge data from the BizTalk Tracking (BizTalkDTADb) database, you must configure the DTA Purge and Archive (BizTalkDTADb) job. This job is configured to call the stored procedure dtasp_BackupAndPurgeTrackingDatabase, which uses the six parameters you must configure in this job.

Prerequisites

---

You must be logged on with an account that is a member of the SQL Server sysadmin fixed server role to perform this procedure.

To configure the DTA purge and archive job (SQL Server 2005)

---

1. On the SQL Server that hosts the BizTalk Tracking (BizTalkDTADb) database, click Start, click Programs, click Microsoft SQL Server 2005, and then clickSQL Server Management Studio.
2. In the Connect to Server dialog box, specify the name of the SQL server where the BizTalk Tracking (BizTalkDTADb) database resides and the appropriate authentication type, and then click Connect to connect to the appropriate SQL server.
3. In Microsoft SQL Server Management Studio, double-click SQL Server Agent, and then click Jobs.
4. In the details pane, right-click DTA Purge and Archive (BizTalkDTADb), and then click Properties.
5. In the Job Properties - DTA Purge and Archive (BizTalkDTADb) dialog box, under Select a page, click Steps.
6. In the Job step list, click Archive and Purge, and then click Edit.
7. On the General page, in the Command box, edit the following parameters as appropriate, and then click OK.
   
   • @nLiveHours tinyint — Any completed instance older than the (live hours) + (live days) will be deleted along with all associated data. Default is 0 hours.
     
   • @nLiveDays tinyint — Any completed instance older than the (live hours) + (live days) will be deleted along with all associated data. Default interval is 1 day.
     
     

     Note
     For the purposes of the BizTalk Tracking (BizTalkDTADb) database, the sum of LiveHours plus LiveDays is the live window of data you want to maintain in your BizTalk Server environment. All data associated with a completed instance older than the live window of data is deleted.
   • @nHardDeleteDays tinyint — All data (even if incomplete) older than this will be deleted. The time interval specified for HardDeleteDays should be greater than the live window of data. The live window of data is the interval of time for which you want to maintain tracking data in the BizTalk Tracking (BizTalkDTADb) database. Anything older than this interval is eligible to be archived at the next archive and then purged. Default is 30 days.
     
   • @nvcFolder nvarchar(1024) — Folder in which to put the backup files.
     
   • @nvcValidatingServer sysname — Server on which validation will be done. NULL value indicates no validation is being done. Default is NULL.
     
   • @fForceBackup int — Default is 0. This is reserved for future use.
     
   The edited command should look similar to this:
   
   exec dtasp_BackupAndPurgeTrackingDatabase 1, 0, 1, '\\MyBizTalkServer\backup', null, 0
   

8. On the Job Properties - DTA Purge and Archive (BizTalkDTADb) dialog box, under Select a page, click General, select the Enabled check box, and then click OK.

Configure the Backup BizTalk Server Job

How to Configure the Backup BizTalk Server Job

You must configure the Backup BizTalk Server job before you can back up BizTalk Server 2006.

When setting up the user account that you are using to back up your databases, note the following:

• You must configure the SQL Server Agent service to run under a domain account or a local account with a mapped user on each instance of SQL Server.
  
• You must configure a SQL Server logon account for this user, and assign this user to the BizTalk BTS_BACKUP_USERS role on each server.
  
• Using a local account for the SQL Server Agent service is not recommended. For example, if you are backing up to a remote computer, you would need to create a local account on the destination system using the same user name and password that you have used on the primary system. If the password were changed on one system but not on the other, the backup job would fail. Using a domain account avoids these issues (and others) and provides centralized account administration.
  
• BizTalk Server includes a SQL Server role named BTS_BACKUP_USERS so that the user account you use to back up your databases does not require System Administrator permissions within SQL Server, except for the primary server controlling the backup process.
  
• The Backup BizTalk Server job can be run under a different account than the SQL Server Agent service account. The general procedure described in How to Configure the BTS_BACKUP_USERS Role for Archiving and Purging Data from the BizTalk Tracking Database can be used to configure the backup job to run under a different user account by changing the database names and user accounts as appropriate.
  

Note
The Backup BizTalk Server job does not delete outdated backup files, so you need to manually manage those backup files to conserve disk space. After you have created a new full backup of your databases, you should move the outdated backup files onto an archival storage device to reclaim space on the primary disk.

Note
BizTalk Server does not write tracking data directly to the BizTalk Tracking database; rather it caches the data in the MessageBox database and then moves it to the BizTalk Tracking database. If MessageBox data loss occurs, some tracking data may also be lost.

Prerequisites

---

To back up your BizTalk Server 2006 databases, you must be logged on with an account that is a member of the SQL Server sysadmin fixed server role.

To configure the Backup BizTalk Server job (SQL Server 2005)

---

1. On the computer that contains the BizTalk Management database, click Start, click Programs, click Microsoft SQL Server 2005, and then click SQL Server Management Studio.
2. In the Connect to Server dialog box, specify the name of the SQL Server where the BizTalk Server databases reside and the appropriate authentication type, and then click Connect.
3. In SQL Server Management Studio, double-click SQL Server Agent, and then click Jobs.
4. In the details pane, right-click Backup BizTalk Server (BizTalkMgmtDb), and then click Properties.
5. In the Job Properties - Backup BizTalk Server (BizTalkMgmtDb) dialog box, under Select a page, click Steps.
6. In the Job step list, click BackupFull, and then click Edit.
7. On the General page, in the Command box, edit the command, and then click OK.
   
   exec [dbo].[sp_BackupAllFull_Schedule] 'd' /* Frequency */, 'BTS' /* Name */, '<destination path>' /* location of backup files */, 0 (default) or 1 /* ForceFullBackupAfterPartialSetFailure */, 'BackupHour' /* local time hour for the backup process to run */
   

   • Frequency: The default is d (daily). This is the recommended setting. Other values include h (hourly), w (weekly), m (monthly), or y (yearly).
     
   • Name: The default is BTS. This is the recommended setting. The name is used as part of the backup file name.
     
   • Location of backup files: Replace '<destination path>' with the full path (the path must include the single quotes) to the computer and folder where you want to back up the BizTalk Server databases. If you specify a local path, then you have to manually copy all the files to the same folder on the destination system whenever the Backup BizTalk Server job creates new files. If you specify a remote path, it must be a UNC share such as \\<ServerName>\<SharedDrive>\, where <ServerName> is the name of the server where you want the files to be backed up using the Backup BizTalk Server Job, and <SharedDrive> is name of the shared folder.
     
     

     Note
     As a best practice for backing up your data, you should specify a computer for your backup that is different from the computer with the original data.
   • Force full backup after partial backup failures: The default is 0 when not specified, which means that if a log backup fails, no full backups are done until the next full backup frequency interval is reached. Replace with 1 if you want a full backup to be made whenever a log backup failure occurs.
     
   • Local time hour for the backup process to run: The default is NULL when not specified, which means that backup job will not be associated with the time zone of the BizTalk Server 2006 computer and will run at midnight UTC time (0000). If you want to backup to run at a particular hour in the time zone of the BizTalk Server 2006 computer, specify an integer value from 0 (midnight) to 23 (11 PM) as the local time hour for theBackupHour parameter.
     
8. In the Job step list, click MarkAndBackupLog, and then click Edit.
9. On the General page, in the Command box, edit the command, and then click OK.
   
   exec [dbo].[sp_MarkAll] 'BTS' /* Log mark name */, '<destination path>' /* location of backup files */ 0 (default) or 1 /* use local time stamps for the backup log */
   

   Modify the parameters in the Command box as needed:
   
   • Log mark name: The default is BTS. This is the recommended setting. The name is used as part of the database log files backup name.
     
   • location of backup files: Replace '<destination path>' with the full path (including single quotes) to the computer and folder where you want to store the BizTalk Server database log files. The <destination path> may be local or a UNC path to another server.
     
     

     Note
     To avoid potential data loss, the <destination path> should specify a computer to store the database logs that is different from the computer with the original database logs.
   • use local time stamps for the backup log: The default is 0 when not specified which indicates to use UTC time stamps for the backup log files. Replace with 1 if you want to use local time stamps for the backup log files and then click OK.
     
10. In the Job step list, click Clear Backup History, and then click Edit.
11. On the General page, in the Command box, change DaysToKeep=<number> to the number of days you want to keep the backup history, and then click OK twice to close the Job Properties - Backup BizTalk Server (BizTalkMgmtDb) dialog box.
    

    Note
    The DaysToKeep parameter specifies how long the backup history is kept in the Adm_BackupHistory table. Periodically clearing the backup history helps to maintain the Adm_BackupHistory table at an appropriate size. The default value for the DaysToKeep parameter is 14 days.
12. Change the backup schedule, if desired. For more information, see Scheduling the Backup BizTalk Server Job.
    

    Note
    The Backup BizTalk Server job runs the first time you configure it. By default, on subsequent runs, the Backup BizTalk Server job performs a full backup once a day and performs log backups every 15 minutes.
13. In the details pane, right-click the Backup BizTalk Server job, and then click Enable.
    
    In the Enable Jobs dialog box, the status changes to Success.

BizTalk DTA Purge and Archive Job failed - Error

make sure @nvcFolder  is accessible from the server. if the default backup location is not accessible it will give failed error.

exec dtasp_BackupAndPurgeTrackingDatabase
0, --@nLiveHours tinyint, --Any completed instance older than the live hours +live days
1, --@nLiveDays tinyint = 0, --will be deleted along with all associated data
30, --@nHardDeleteDays tinyint = 0, --all data older than this will be deleted.
'C:\DTABackup', --@nvcFolder nvarchar(1024) =N'C:\DTABackup' , --folder for backup files
null, --@nvcValidatingServer sysname = null,
0 --@fForceBackup int = 0 --

500 Internal Server Error .Too many open files....

500 Internal Server Error . Client was getting following error while accessing the form application.

 The OC4J log file shows

formsweb: Servlet error  Or web: Servlet error

java.io.IOException: Too many open files

Cause
On Windows systems , there is a limit to the number of files that can be simultaneously opened : about 2000.
On unix it is 1024.the problem could cause due to antivirus software running in the server or for any other updates running as well.
This limit applies to all the servlets running in the OC4J_BI_Forms : The forms Servlets and the Reports Servlets. 
Solution
To increase the parameter numprocs for the OC4J_BI_Forms : 

1. Edit the file ORACLE_HOME\opmn\conf\opmn.xml 

2. Locate the following lines :
....
process-type id="OC4J_BI_Forms" module-id="OC4J">
....
process-set id="default_island" numprocs="1"/>
/process-type>
.....


3. Replace :
numprocs="1"
by
numprocs="2"

4. Execute the command : 
$ORACLE_HOME/bin/opmnctl reload 
in order to reload the file opmn.xml

The modification will be taken into account the next time the OC4J_BI_Forms will be restarted.

When numprocs > 1 , several processes will be started for the OC4J OC4J_BI_Forms. It means that the requests will be "load-balanced" between the 2 processes.
So, the number of files opened will be divided by 2 (if numprocs=2) and the limit will no more be reached.

FRM-92101 Error When Running Forms

FRM-92101 Error When Running Forms After 70-75 Concurrent Connections and No New Connection Possible

This problem is specific to MS Windows Operating Systems - normally Windows 2000 or 2003.  Although the occurrence of this issue is not common, it appears on both 32 and 64 bit windows.  You may receive the following error indications:

Forms 6i, 9.0.4.X, 10.1.2.X - FRM-92050 sometimes together with FRM-92101 or FRM-92102
Forms 9.0.4.X, 10.1.2.X - application.log shows FRM-93000
Forms 6i (Forms Listener Servlet) - jserv.log shows FRM-93000
Forms 6i (Forms Server) - error log shows ERROR 1444 - FORMS SERVICE STOPS UNEXPECTEDLY 1444

This happens with a small number of connections - the range may be 50 - 80. The specific number depends on operating system factors such as number of CPUs, processor speed, memory, etc.   The problem may occur even with less than 50.  

CAUSE

Windows has a memory resource called the Desktop Heap. A particular section of this  resource is running low and causes the problem.

SOLUTION

1. Change the logon-property from the responsible service to "[x] Allow service to interact with desktop" (using all the defaults of the registry!) and restart the service.

This forces the Apache Service (Forms 6i) or the Oracle Process Manager Service (OPMN) (Forms 9i and above) to use the IO Desktop heap which is larger than the Non-IO Desktop heap by default. The term "Desktop", here, is not to be confused with the normal Windows desktop, which holds your icons and your background, etc. In this context, it is Microsoft terminology for an area of memory.

Once verified that this increases the number of possible frmweb processes, then return this setting back to its default value - unchecked -  and modify the Non-IO Desktop Heap size in the Registry as it is used by the Middle Tier OPMN Service.
2. Modify the Non-IO Desktop Heap size variable in the registry. This should not be done unless:
- A backup has been made of the registry. Any error in modification of the registry can render the system unusable.

- Solution 1 has been tested and has increased the number of processes that will run successfully.

The following information applies to Windows NT, Windows 2000, Windows 2003.
Enter the Registry and go to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SubSystems.

Double click on the Windows node value in the right frame.  Increase the  appropriate SharedSection parameter which will be the third one.  For example, the SharedSection specifies the system and desktop heaps using the following format: 

SharedSection=xxxx,yyyy,zzzz The default values are normally 1024,3072,512

All the values are in kilobytes (KB).

xxxx = System-wide Heapsize. There is no need to modify this value and it is ignored for the rest of this discussion.

yyyy = IO Desktop Heapsize. This is the heap for memory objects in the IO Desktop and there is normally no need to modify this value. Programs that are run from a command line (.bat files) or an icon use this memory resource.

zzzz = Non-IO Desktop Heapsize. This is the heap for memory objects in the Non-IO Desktop and is used by programs that are spawned from a service. Therefore, this is the value that should be increased if the OPMN process is being started as a service which is the default for a windows installation of the Application Server. This number can be set as high as 30 MB (30720 KB). However, it is seldom necessary to set it this high.

If you change these values, you must reboot the system.
The values are recommended to be a multiples of 512, but this isn't necessary. There is a hard limit total of 48 Mb for the the total heap size for Windows.

If you increase the Non -IO Desktop heap and your server is dedicated to Forms
or some other server process , then you can safely decrease the IO Desktop heap
since that is just wasted. This isn't necessary, though.

In summary, if you are hitting this problem where your server can not create
any more processes, you should increase the heap size of the either the IO
Desktop or the Non-IO Desktop. The correct one depends on how you run your
application, whether from a service, or from an icon or command line.

You have to restart the all services from Oracle AS, after saving the changes.

Explanation

---

This is an Operating system limitation on the heap sizes.

Oracle Forms and JavaScript Integration 11g

Oracle Forms and JavaScript Integration

This chapter contains the following sections:

• Section 6.1, "About Oracle Forms Calling External Events"
• Section 6.2, "About JavaScript Events Calling into Oracle Forms"
• Section 6.3, "Configuration of formsweb.cfg"
• Section 6.4, "Configuration of Environment Variables"

6.1 About Oracle Forms Calling External Events

In previous releases of Oracle Forms, you had to implement OLE and DDE to interact with a limited number of event types outside of Forms. In later versions, Forms offeredweb.show_document and Java integration to interface with external application sources. But in terms of calling out to the Web page where Forms is displayed, there was no easy solution. It was also not possible to call from the Web page into Forms, perhaps to update a value acquired from an HTML form.
In Oracle Forms 11g, JavaScript integration provides the ability to have JavaScript events call into Forms, or have Forms execute JavaScript events. Figure 6-1 shows howJavaScript and Oracle Forms work together. In the left side of the image, JavaScript is executed in the page in which the Forms applet is hosted. Oracle Forms now has the capability to call JavaScript functions using native built-ins. Also, JavaScript functions can now trigger a Oracle Forms trigger by using a new API that has been provided.

Figure 6-1 Oracle Forms and JavaScript

Two new calls are available in the web Built-in package:

• web.javascript_eval_expr
• web.javascript_eval_function

The first call web.javascript_eval_expr is a procedure which takes two arguments: an expression and a target, both of data type varchar2. This legal JavaScript expression is interpreted in the Web page in which the Forms applet is embedded. The expression can be a call to a function that is defined in the target page or any valid JavaScript expression that can be executed on the target page, for example, document.bgColor='red'. The expression is executed, using LiveConnect's JSObject.eval() method, in the context of the page or frame that is named in the target argument. If the target argument is null, then it is executed in the page or frame in which the Forms applet is embedded.
The second call, web.javascript_eval_function is a function and returns a varchar2 value. Both web.javascript_eval_expr and web.javascript_eval_functionhave the same functionality except that javascript_eval_expr does not send any return value from the Forms client to the Forms Services. If your application does not need a return value, use web.javascript_eval_expr. The additional network trip that is required to carry the return value from the Forms client to the Forms Services is eliminated.
To set the value of an HTML text item with the ID outside_field_id to the value of the Forms field called inside, you could write this PL/SQL code:

web.javascript_eval_expr('

document.getElementById("outside_field_id").value='

||:inside

);

Note that the PL/SQL string must use single quotes while JavaScript is flexible enough to use single or double quotes. Using double quotes inside the expression works without having to use escape sequences. You could also write a function in the Web page:

<SCRIPT>

    function set_field(field_id, myvalue){

        document.getElementById(field_id).value=myvalue;

    };

</SCRIPT>

To get the value of the outside field and assign it to the inside field, you could write the following PL/SQL code:

:inside:=web.javascript_eval_function('

     document.getElementById("outside_field_id").value

     ');

6.1.1 Why Call Events Outside of Oracle Forms?

In Oracle Forms 11g, the newly added JavaScript functionality allows you to integrate Forms with HTML-based application technologies in the Web browser. For example you can use JavaScript integration when the Forms-based application is required to integrate on the page with new functionality based on an HTML front end.

6.2 About JavaScript Events Calling into Oracle Forms

You can also allow JavaScript calls into Oracle Forms by using JavaScript in the Web page that hosts the Forms applet. There is new functionality available on the embedded Forms object in the DOM (Document Object Model) tree. You use JavaScript to do:
document.forms_applet.raiseEvent(event_name, payload);
The assumption here is that you have set the ID configuration variable to forms_applet.
When the surrounding Web page executes this JavaScript code, Oracle Forms fires a new type of trigger called WHEN-CUSTOM-JAVASCRIPT-EVENT. In this trigger there are only two valid system variables: system.javascript_event_value and system.javascript_event_name. These variables contain the payload and event name that were passed into Forms through the raiseEvent method. On calling the raiseEvent method, a trigger named WHEN-CUSTOM-JAVASCRIPT-EVENT is fired on the server side.

declare

    event_val varchar2(300):= :system.javascript_event_value;

begin

    if (:system.javascript_event_name='show') then

        handleShowEvent(event_val);

    elsif(:system.javascript_event_name='grab') then

      handleGrabEvent(event_val);

    else

        null;

    end if;

end;

This PL/SQL code recognizes two events: 'show' and 'grab'. Any other name is ignored.

6.2.1 Why Let Events Call into Oracle Forms?

You can synchronize an HTML based application, whether it is Java-based or otherwise, with a Forms-based application in the same hosting Web page. For example, you can use the HTML-based application to query data and use Forms to update it if, and only if, the user has the correct access privileges.

6.3 Configuration of formsweb.cfg

The administrator of the Forms application can enable or disable JavaScript integration by setting the parameter enableJavascriptEvent in formsweb.cfg to "true" or "false". If enableJavascriptEvent is not set to true, then calls from JavaScript would be ignored. The applet_name parameter must be set to the value that is used by the HTML developer to reference the forms applet via document.<applet_name>.
The administrator can also set JavaScriptBlocksHeartBeat (default value is false) in formsweb.cfg to true. This blocks Form's HEARTBEAT during the time JavaScript is executed. If the JavaScript calls complete execution before the FORMS_TIMEOUT period, setting JavaScriptBlocksHeartBeat to true provides an increase in performance by avoiding additional network messages.
Note that if JavaScriptBlocksHeartBeat is set to true, Forms would abnormally terminate if the time taken for executing a JavaScript is more than FORMS_TIMEOUT.

6.4 Configuration of Environment Variables

An environment variable called FORMS_ALLOW_JAVASCRIPT_EVENTS in default.env is also used to enable or disable JavaScript integration. By default, the value of the variable is true. If this is set to false, then JavaScript integration is not enabled for any Forms aplication that uses that instance of default.env, no matter what value is set for enableJavascriptEvent in formsweb.cfg.