SILKPERFORMER AND ORACLE FORMS SUPPORT

A SEGUE SUPPORT WHITE PAPER

Author: David Mc Leish

The aim of this paper is to give an introduction to Oracle Forms, how to setup SilkPerformer to do a recording and replay. The paper will also aim to give some insight into the record and replay logs so that all engineers will have a more full understanding of Oracle Forms.

Oracle Forms Basic concepts

Oracle Web Forms allows you to run your existing Oracle Forms applications in a browser. In previous versions, the user interface and complete client/ business logic where executed on the client machine in the Oracle Forms Runtime. The move to Web technology split these components: There is still an Oracle Forms Runtime that performs the client/business logic on an application server. However the runtime has been separated from the user interface by sending/receiving user interface actions to an applet that runs in a browser.

Client (browser) ---

App Server

DB Server

The Oracle Forms Web client is a Java applet hosted within a browser. Its possible to use your browsers default Java Virtual Machine (i.e., Internet Explorers MS JVM or Netscapes JVM). However because there have been some issues with these JVMs, Oracle provides its own JVM, which is called JInitiator. The JInitiator is installed automatically when you access an Oracle Forms Web application for the first time. The reason that Oracle decided to develop their own runtime, is because of the Java Runtime that is used by MS or Netscape is subject to the limitations and defects of the vendor. Oracle wanted to overcome issues with the Java Runtimes, issues such as known bugs, limitations etc. So Oracle created their own runtime (to host the applet). With this approach, Oracle have ensured that their applet is always executed in an environment that they have tested and where they know that everything should work fine and is not subject to vendor related issues. If Oracle had not done this - it could be possible that they might have faced support issues. SilkPerformer version 6X has introduced the support for Oracle forms. At present the following versions are supported: Oracle Forms Release 6i Oracle 9i Forms Oracle Forms 10g (which is 9.0.4) Oracle Applications 11i (Oracle E-Business Suite 11.5.x).

There are two main versions: Oracle Forms 6 pre and prior patch 4 Oracle Forms 9 These two versions are almost the same but there is a slight difference between them. Whereby version 6 has two major revisions, version 6 pre and prior to patch 4. In the pre patch version the client connects to the Forms server and a HTTP listener process will return the html page that will contain all the information on the Oracle Forms applet. The applet will then connect to a Forms server listener process, this process is responsible for spawning a new process that will host the Forms Server runtime for the client. Therefore the client applet and Runtime Engine will have a direction connection via HTTP or HTTPS. In the prior patch 4 version, the communication architecture has been changed to only have one communication channel between the client and the Oracle Forms server. In version 9 the communication channel has not changed, but there has been a change. The difference lies on the client side. A new JInitiator that runs on Java Runtime Version 1.3.x can be used for version 9, allowing custom applications to develop Java GUI or Java Beans that rely on a newer JDK

This significant change in Oracle Forms 9 impacts the way that SilkPerformer records and replays messages that are sent between the client applet and the Oracle Forms Server. Oracle has introduced a test interface that can be used to retrieve all messages during recording and send those messages to the server during replay. As a result of the change in the different versions architecture, SilkPerformer has had to employ different approaches to recording the Oracle Forms versions. When you select version 6 the recorder can listen on two communication channels (HTTP and Socket layer) whereby version 9 will only cover one communication channel. So as a result of this change SilkPerformer distinguishes between Oracle Forms 6 and Oracle Forms 9 and the fact that they have different approaches to recording/replaying. Therefore Segue felt is was necessary to have to have to separate project types when setting up a new project. Now we move on to setting up your machine and SilkPerformer to be able to install and record Oracle forms.

Configuring Oracle Forms Client Software

Oracle Forms clients run in Web browsers as applets. By default, a Web browser will download and install Oracles default Java Runtime when loading an Oracle Forms application for the first time. Once a JRE has been installed and the appropriate Active Profile settings have been configured, SilkPerformer will be set up to record Oracle Forms applications.

Recording
Before recording you will need to ensure the following: 1. The Oracle Forms client must be running on the recording machine. 2. You know which version of Oracle Forms you're testing: Oracle Forms 6, Oracle Forms 9, or Oracle Applications 11i Setting Up an Application Profile: Firstly you will begin by setting up an application profile, to do this go to File | New Project | Application Server/Component Model Now select the appropriate Oracle forms version from the list as shown below: Note: If you are unsure as what version of Oracle Forms server you are testing, you can use the SilkPerformer recorder to connect to the server and check the source code of the page. To do this browse to http://forms90.austria.segue.com:7779/forms90/f90servlet?config=HL and select View | Source, the source code of the page will now open in your text editor. In the editor search for PARAM NAME="ARCHIVE" Once you have located this field you will see that there is a value associated with this parameter. For example: <PARAM NAME="ARCHIVE" VALUE="f90all_jinit.jar" > This will inform you that your Oracle Forms server is using Oracle forms 9i and that you should select Oracle Forms 9i for your project type

Please note: If you have Oracle Applications 11i, you can either choose the Oracle Forms 11i project type under the ERP/CRM node or you can select Oracle Forms 6i as shown above The reason for this is that Oracle Forms 11i operates on the same technology as Oracle Forms 6i, so either application profile will allow a successful recording. Currently SilkPerformer version 7.0 supports the following Oracle Forms versions: Oracle Forms Release 6i Oracle 9i Forms Oracle Forms 10g (which is 9.0.4) Oracle Applications 11i (Oracle E-Business Suite 11.5.x). Oracle Forms applications are recorded by recording your default browser (which will more than likely be IE) and using a special Java Recording API that captures the messages that are sent between the client and server. When choosing one of the Oracle Forms project types in your application profile settings, a new application profile is created for your project based on the active browser. To view the new profile go to: Settings | System Settings | Recorder | Application Profiles | Oracle Forms 9i application

Java Environment Settings

Now we move on to ensuring that our systems java settings are compliant to allow us to hook and record the Oracle forms application. The reason for this is that Oracle Forms applications is achieved via a Java implementation, so its necessary to configure your Java environment in SilkPerformer. This configuration can be done either system-wide using the System Settings dialog, or it can be done on a per-project-basis using the Profile settings dialog. However, I recommend that you create this system wide to save you having to set this up each time. The Java settings allow you to define the following: - Version of your Java Runtime - Java Home Directory - Additional classpaths (you don't need to define these for the recording of Oracle Forms) - Advanced settings such as Command Line Options, JITting, and special JVM.dll's (not required for Oracle Forms recording) To set the Java settings please do the following, click Settings | System Settings | Java | General Tab This will look similar to below:

Once you have defined the correct runtime please switch to the Advanced tab in the window In this window you can now test if your machine is correctly configured to use the specified java environment. To do this, please select the option Check JVM. If the settings are correct and compliant then the following message will be returned

If the settings are not correct then you will get a message similar to below displayed:

This message informs you that you have either not set the correct home location or that you need to set the correct version etc.

LOGGING
Before actually recording the application one more set of options have to be set, the hook logging options. To set please go to: Settings | Active Profile | Record | Results | Logging | Log all

And Settings | Active Profile | Record | Oracle Forms | Logging | Log level | Select Debug These settings will allow as much information to be collected as possible about the recording process, this will be very valuable should the case go to development.

RECORDING
Now we move on to the actual recording of the Oracle Forms application.

Start Recording
Begin recording by doing the following: - Select Model Script from the workflow bar. - Select an Oracle Forms application profile. - Enter the URL of your Oracle Forms application and click. OK

To have a working example please use the following URL:

Segue Software demo Oracle Forms server at

http://forms90.austria.segue.com:7779/forms90/f90servlet?config=HL
Or a free server at http://siam.thf.ch/servlet/f60servlet?config=demo When testing this demo server the first thing you will notice is that the application will take a long time to load and may appear to hang, do not worry The reason for the apparent hang is that Internet Explorer (or your browser) is trying to download the applet that the oracle forms application will load in. This is only done once when the application is first initialised and for this reason it is best to do this manually in the browser before beginning to loadtest. To avoid any misunderstandings while recording, I recommend that you visit the Oracle Forms server at least once prior to recordings. We should stress this to all customers. When they visit the site outside of SilkPerformer the necessary files will be downloaded and the

recording will appear to be smoother and the customer will not think there is a recoding issue due to the long delay to load the applet. For full details on the applet loading please see:

http://support.segue.com/kbshow.php?q=17445

Setting up a Java Runtime for Replay

A Java Runtime must be installed on each SilkPerformer agent machine. Its recommended that the latest Java Runtime distributed by Sun be used. The directory containing the Java Runtime must be the same on each SilkPerformer agent machine. To ensure that the agent machines meet the pre-requisites please follow the checklist below - Install Java Runtime on each SilkPerformer agent machine. - Install the latest Java Runtime distributed by Sun - Make sure the JVM installation directory is the same on each SilkPerformer agent machine

Generated Script: In this section I will look into the key functions generate by the OraForms recorder and aim to include some examples to give a better understanding of the functions in the script. Key Functions in BDF: The script contains the OraFormsInit method call in the init transaction. This defines the server, port, servlet URL and version of your Oracle Forms application. Not all parameters will necessarily be scripted with values as required parameters vary based on version and connection type. Example from recorded script: OraFormsInit("http://forms90.austria.segue.com:7779/forms90/l90servlet", "forms90.austria.segue.com", 9000, ORA_FORMS_9I); So from the example above we can see the following: Server - forms90.austria.segue.com Servlet Url - http://forms90.austria.segue.com:7779/forms90/l90servlet Port 7779 Version - ORA_FORMS_9I OraFormsInit initializes the internal Oracle Forms Replay Engine (the actual connect is achieved with OraformsConnect and therefore should be one of the first calls in the main transaction. OraformsConnect This function is responsible for establishing the connection between your Oracle Forms client (SilkPerformer) and an Oracle Forms Server. Example from recorded script: OraformsConnect ("server module=healthyliving.fmx sso_userid= output_dir=c:\\ora90app\\forms90\\demos\\temp userid=HL/HL@orcl_sunserver r" "ecord=names",http://forms90.austria.segue.com:7779/forms90/l90servlet?ifcfs=/forms90/f90 servlet?config=HL", "http://forms90.austria.segue.com:7779/forms90/"); Wherever a new form window is activated the recorder scripts a OraFormsSetWindow ", indicating that the new window is now the active window. In the recorded script you should see a comment scripted above the OraFormsSetWindow function call, this will allow you to follow the script:

// New window activated: MAIN OraFormsSetWindow("MAIN"); All of the subsequent method calls (OraFormsSetWindow) are executed on controls of the current window. OraFormsDestroy is scripted in the end transaction to shut down the replay engine. This function is scripted in a separate transaction as the example below shows, the reason for this is that the function is responsible for shutting down the Oracle Forms replay engine and therefore is only permitted to be called in the TShutdown transaction. Transaction TShutdown begin OraFormsDestroy(); end TShutdown; If the destroy function is called outside of the Tshutdown transaction the script will execute the function and close the Oracle Forms replay engine, as a result of this the script will shutdown and call the following function: OraFormsDisconnect with Transaction Exit on OraFormsSetWindow and all subsequent Oracle calls will fail.

Recording secure Forms at HTTPS level

Please note that to record an Oracle Forms application that uses a secure connection via HTTPS several prerequisites have to be made for both record and replay. Record On record you need to ensure that you have the exact server certificate needed for authentication with the server. This server certificate will have to be imported into SilkPerformer. To record an Oracle Forms application over HTTPS you must extract the server certificate from your Oracle Forms application server and store it on a file server that is accessible by the recording computer. The certificate file (.pem) to be used with Silk Performers recorder consists of the servers certificate and a private key. This file must be created manually. In order to create this file please see the list below: Make a copy of the private key (e.g., use the command prompt: "copy certsignkey.key yourCert.pem") Append the server's certificate (e.g., use the command prompt: "type cert.crt >> yourCert.pem") The file to be used as a server certificate in Silk Performers recorder is now created. The extracted certificate file (.pem) must be specified in the recording profile settings of your Oracle Forms project: To ensure the Project is set up correctly please follow the check list below Create a new Oracle Forms project Open your profile settings at Settings | Active Profile | Record | Internet Select the Recording option in the window Enable the option (by checking) Use custom server certificate and specify the location of your exported server certificate Specify the Pass phrase for your certificate if it is protected by a password SilkPerformer will now be fully configured to record your secure application.

Replay Before replaying the recorded Oracle Forms HTTPS script you must do the following: Open a command line prompt in your JDK directory Execute the following command: keytool -import <CERTIFICATE_ALIAS> -file <CERTIFICATE_FILE_PATH_AND_NAME> -trustcacerts Where CERTIFICATE_ALIAS is any alias name that you can choose and CERTIFICATE_FILE_PATH_AND_NAME is the complete filename to the server's certificate file (.crt) A file called ".keystore" has been created in the user's home directory (\documents and settings\username for Windows2000 and WindowsXP). Copy this file to your SilkPerformer project directory Add the keystore file to your project's data file section to do this please go to: Settings | Active Profile | Replay | Java | Advanced and now add the value listed below to the command line options window; Djavax.net.ssl.trustStore=.keystore

The reason you need to import the Java Keystore certificates is because the Oracle Forms replay engine is purely developed in java and makes use of the java keystore application that stores the necessary certificates. So you need to use the Java SSL libraries rather than Open SSL libraries as you would in a web application Oracle Form TrueLog file The details below will give a brief summary of the structure of the Oracle Forms XLG, the information we log for each control and the options available within the TrueLog Explorer to allow users to insert parsing and verifications etc. Structure Each OraFormsSetWindow call will result in a new top-level node; this will be displayed in the left pane of the TLE. All actions that are performed on a window will be shown as sub level nodes of the original top-level node. In addition to the Oracle Forms API calls the TLE will also log the http content, so the TLE will also display embedded content such as images and style sheets etc. Node information Each node will store the current state of the controls of the active window. So the lop level node as created by the OraFormsSetWindow API will show the windows first appearance and hence all the controls and values will show as they existed when the form was first created. See image below

However, if you drill further down into the TLE, say after you have changed a control on the window. You will clearly be able to see that the form now has new values that differ from when the window was first activated. See image below this shows that the control named Prod_Product_Name_0 now has a new value of Test1

This is one the main benefits of the Oracle Forms TrueLog Explorer; we can visually check the status of each window as the new controls values are updated as a result of the users interactions. So what do the columns mean in the Forms Controls window? To explain this lets look at the image below

In the above image we see 7 columns, the details below will explain what each of these represent: Change State Column The first column (which does not have a title) is known as the change state column. This is used to inform users of the current state of the control. This will be used to list the state of a control at the current time. So in the above image we can see that the control named Prod_Description_0 has a state of EDIT. This informs us that the control has been edited via the API function OraFormsEditSet. If the control has a grey line and no state listed, then this control is inactive in the current window and no state needs to be listed. ID Column: This is the unique control ID of the control. This ID is used in the messages that are sent between the client and server in order to define handles to control messages Name Column: This is the internal name for each control on the forms window. So in the above image we can see that we are currently editing the control named Prod_Description_0. SilkPerformer will record the programmatically defined named of the control, as working with names is much easier than working with control ids and make the logs much easier to read Type Column: This lists the type of the control. So in the example above the product description control is a text box. In the TLE we can have a number of different control types such as Tab. Button, Tree, List, Radio and Check.

Value Column:
This is the current state of the control. So from the example below we can see that the Control named Prod_Description_0 is a text box, which currently holds a control value of Test for Dee C/S Column: This column is used to indicate if a value of the control is changed. The C will indicate that a client side factor has changed the value. An S will indicate that a server side factor has changed the value. Old Value Column This column will show the previous value before the client or server side changed the control to a new value. So you may ask in the example above, why does the old value only show as T? The reason that we only see the first character is because edit controls have a special behavior in Oracle Forms. The current value of an edit control will be sent as soon as you change the value. The first character that you enter that changes the value in a text is sent. So, if we enter the value Test for Dee in a blank field - 'T' is sent first and after the user has entered the complete value, only then will 'Test for Dee' be sent. So if we enter the value 'Test for Dee again' in a field where the previous value was 'Test for Dee then 'a' will be sent first and then, when the complete value has been entered 'Test for Dee again' gets sent to the server. In the TrueLog Explorer what do the coloured lines symbolise? When viewing an XLG file in the TrueLog Explorer, we provide a key or legend to enable the users to distinguish what is happening within the form control windows. We do this via colours; each colour will represent a different action. Purple: This colour is used to indicate that the form control now has focus. When the control has focus you will see the purple line on the control and you will also see the word focus or

Press in the change state column. This colour indicates that the form control now has focus in the forms window, this focus has been granted either via direct clicking or the tab key. Yellow: This colour is used to indicate that the form control has been edited, meaning that values have been input on record of the script. Faint/Grey line: Sometimes you may notice a faint or grey line in the form controls window. This colour indicates that a value has been created, but is currently not visible to the user in this window. Visual Verification and Parsing Within the Oracle forms TrueLog Explorer we offer many wizards to make the customisation and verification of test scripts as simple as point and click. This is a massive benefit to Segue customers, as they do not need to have a programming background to be able to successfully customise scripts. To activate any of the wizards simply select the value of the control you wish to customise and then rightclick and select the option you require.

Data Customisation Input data customisation is also available in the TrueLog Explorer, this is available via a wizard to guide you through the entire process. The wizard gives you several input parameter options, as shown below. This enables the user to make the script as robust and durable as possible, as they have the option to use a constant value, another variable or even pull data from a CSV file.

Reading Record and Replay log files. RECORD LOG: After you have successfully completed a record of the Oracle Forms site open the record log and you will see the key record log entries I will discuss below: 1. Spy DLL initialised ... Start recording WinSock traffic of application: C:\Program Files\Internet Explorer\IExplore.exe The above entry simply states that the recorder has hooked into the Internet Explorer executable file to allow us to generate the script. The Internet Explorer exe file is used, as Oracle Forms is an applet that runs in the browser. 2. JavaHookingEngine(JC): reconfigure(logLevel=2, configfiles='C:\Program Files\Segue\SilkPerformer 7.0\classfiles\OraForms.xjh') and other JavaHookingEngine(JC) calls. 3. Advanced settings in effect This keyword informs us that the list of settings that are active during the record. The advanced settings rule is always active for all recordings; this entry in the log file simply informs us which settings are applied to this record. For full details on the advanced settings rules ask Mark the recording rules king Boomer. 4. JavaHookingEngine(NC): Function timing for 'Action ', duration: xx.xx ms This entry simply states that timers have been collected for certain java methods/action calls. The timer is listed as the duration time in milliseconds 5. You will now see many HTTP level API calls similar to what you would see in a web script. You will see calls such as - WebPageUrl - WebSetBrowser - WebCookieSet etc. 6. OraFormsSetInt /OraFormsSetString etc. These functions simply tell the recorder the connection properties to use when connecting to the Oracle forms server via the function OraFormsConnect 7. OraFormsGetSessionId(gsSSessionID); Once a connection with the Oracle Forms server is established, OraFormsGetSessionId can be used to capture the session ID cookie that was returned by the server during the connect process. The recorder automatically scripts OraFormsGetSessionId and a WebCookieSet with the session ID on the applets codebase. This ensures that all recorded HTTP requests use the session ID when additional files are requested that require valid session IDs So the captured session ID will then be used as a cookie throughout the rest of the test, example: WebCookieSet(gsSSessionID, "http://forms90.austria.segue.com:7779/forms90/java/"); 8. In the log you will be able to see the start of the connection to the forms server and the final disconnect. These are shown via the opening connection on OraFormsConnect(); And the closing connection on

OraFormsDisconnect(); Between the opening connection and the closing connection in the log, all actions and forms controls accessed will be logged; most of these will be self-explanatory. 9. In the record log we will see many Java entries, such as JavaHookingEngine(JC): reconfigure(logLevel=2, configfiles='C:\Program Files\Segue\SilkPerformer 7.0\classfiles\OraForms.xjh') JavaHookingEngine(JC): Reading hook configuration file 'C:\Program Files\Segue\SilkPerformer 7.0\classfiles\OraForms.xjh' JavaHookingEngine(JC): getAllExtraRuleFiles These entries are more related to our general java recording functionality. The reason for this is that when recording at Oracle Forms level the SilkPerformer recorder will hook into the java classes of the Oracle Forms applet. So therefore hooking is done with our java recording functionality and it is this engine that is making these log entries. 10. Java-Environment Settings: The details listed under this header, is the information we log about the java runtime that is used by the Oracle Forms applet. This information is very useful to get a feeling about the environment that the customer is using. Java-Environment Settings: ========================== java.version = 1.3.1.9 java.vendor = Oracle Corporation java.vendor.url = http://www.oracle.com/ java.home = <no access> java.vm.specification.version = 1.0 java.vm.specification.vendor = Sun Microsystems Inc. java.vm.specification.name = Java Virtual Machine Specification java.vm.version = 1.3.1-rc2-b22 java.vm.vendor = Sun Microsystems Inc. java.vm.name = Java HotSpot(TM) Client VM java.specification.version = 1.3 java.specification.vendor = Sun Microsystems Inc. java.specification.name = Java Platform API Specification java.class.version = 47.0 java.class.path = <no access> java.ext.dirs = <no access> os.name = Windows 2000 os.arch = x86 os.version = 5.1 file.separator = \ path.separator = ; line.separator = user.name = <no access> user.home = <no access> user.dir = <no access> REPLAY LOG: 1. At the start of the log you will see the usual logging data that is set for each replay file. So you will see: Version / Project/ Benchmark/ BDF file. / Time and Date etc

2. Next up you will see the normal HTTP HttpRequestHeader and HttpResponseHeader being sent from the client to the server and back from the server to the client. These API calls will contain the normal standard HTTP headers, such as GET/ Host/Accept / Cookies etc 3. We now see the Oracle Forms applet being received from the server WebPageUrl(#1176, HttpResponseBody, "/forms90/f90servlet?config=HL") The response the client receives will be a HTML page that contains the content/parameters that make up the applet. 4. Throughout the log file all HTTP traffic will follow the normal format: HttpRequestHeader - Client sending request to the server HttpResponseHeader Server sending reply to the request header back to the client HttpResponseBody The server will now send the full HTML content of the response back to the client. 5. On replay we will see that all Oracle Forms API calls messages have a particular format. This formation can be see in the example below: ===> Block# 1 --------------------MSGTYPE: UPDATE CLASS: 1/1/0 ID: 1 RESPONSE: 0 PROPERTIES: TYPE: PROP_TYPE_INTEGER Name: INITIAL_VERSION/268 Value: 90290 From the example above I will detail what each section means: ===> Indicates the direction of the message. So in the example above we can see that the message is from client to the server. If we seen <=== then we would know that the message was from the server to the client. Block# The block consists of the message sent to the server or from the server to the client. MSGTYPE: This indicated the message type that the block is sending. The messages can be any of the following:

CREATE : This message is sent by the server to tell the client that a new control/window/etc. needs to be created. The create message contains the unique control type (the number from registry.dat). The message will also contain a unique control id that is assigned to the control. All following messages for this control contain this unique id. UPDATE : The server sends an update message to tell the client about changes on a control, e.g.: value of a text field. The update messages will contain the unique control id, therefore the client knows which control to update in the applet. The client sends an update message if the user changed a value of a control. This action is done so that the server is informed about the current state of every control on the

client. GET : The server or client can request the current value of a control. To request this value a GET message is sent. DESTROY : The server informs the client that a control/window should be destroyed. TERMINAL : This is the terminating part of the message. See information on point 8 below for full details on this message. CLASS : The class controls that is responsible for handling the messages. ID : The unique control identifier that handles the messages. RESPONSE : This is the Status response of the message. The response number allows the client and server to switch roles. In some cases it is possible that the client switches in server mode i.e. the client sends some messages that normally the server is sending. Currently this information is too technical too describe but the number of the response will determine who plays which role. The response will show either of the options below 0 indicates This will indicate client 1 indicates This will indicate server Note: A response number of 1 can also be returned. This will be sent in case of a server error. In the example above we have a sample message, in this sample message we see the list of the properties of the message. So we see a property type, name and a value of the property.

6. In the replay log file you will be able to see all the replay settings that the test script has used on replay.
General Settings() Internet settings () Oracle Forms Settings() These settings will list all the Active Profile settings that were active for the Vuser simulation. 7. In the replay log see the following request for a registry file WebPageUrl(#1180, HttpResponseBody, "/forms90/java/oracle/forms/registry/Registry.dat") { #\n #ThisistheRegistryfile.\n #\n In Oracle Forms every control type is identified by a unique id. You see the control type id when you have a look at a CREATE message as described above. The file Registry.dat will contain all the information about which java class in the applet implements a certain OraForms control type. 8. In replay log I see the following:

++++++++++++++++++++ TERMINAL MESSAGE ++++++++++++++++++++ In Oracle Forms, the communication will start with the client sending some information to the server. The server will then respond to this initial message, the message will be sent back to the client. This asynchronous communication will continue between the client and the server, until the last message is received from the client to the server. The termination message is sent both ways, so the client can receive the message from the server and the server will receive the termination message when the client has stopped sending the full message. The last message is know as the TERMINAL message. When the terminal message arrives at the other side (Client/Server) the recipient will now know that it is their turn now to send a response to the messages it has received. So, the TERMINAL message is like a token message telling the opponent that this is the full message(s) has been fully communicated. 9. OraFormsSetWindow("MAIN") { } : NULL writeControlState for: MAIN children 15 addControlState for: CONTENT addControlState for: CONTROL_DUMMY_0 addControlState for: SUPPLIER_INFO_CAN addControlState for: SUPPLIER_TAB addControlState for: UPLOAD_FILE_UPLOAD_BEAN_0 addControlState for: SHOW_IMAGE_CAN addControlState for: vertical_toolbar addControlState for: CONTROL_WELCOME_BUT_0 addControlState for: CONTROL_SUPP_BUT_0 addControlState for: CONTROL_PRODUCTS_BUT_0 addControlState for: CONTROL_SAVE_BUT_0 addControlState for: CONTROL_EXIT_BUT_0 addControlState for: SUPP_SUPPLIER_NAME_0 addControlState for: SUPP_SUPPLIER_PASSWORD_0 addControlState for: SUPP_LOGIN_BUT_0 setTrueLogFlushBehavior to 5 addControlState for: vertical_toolbar_1 addControlState for: 12 addControlState for: LEFT_FRAME addControlState for: WELCOME_CAN addControlState for: SUPP_CONTACT addControlState for: SUPP_BANKING addControlState for: PROD_TREE_CAN finish Node! setTrueLogFlushBehavior to 5 The above log entries are very specific to our technical implementation of Oracle forms and should not bother our users. These log entries are created so that we can log the information about the control types that we need to store in the TrueLog. addControlState Means that we log all control information about a certain control to the truelog. finish node means that we are finished with the current truelog node and depending on the current flush behavior what actions will be taken next. setTrueLogFlushBehavior These entries will tells us when we really end the TrueLog node.

Before we finish this section I have enclosed a small section called hints and tips. This section is listed in the official Oracle Forms White Paper but it is near the end of the paper and I am sure that not all of our engineers will have seen this.

TIPS AND TRICKS Multiple Transactions When using multiple transactions it is recommend using the same connection. So in scenarios whereby you may have a login procedure and multiple transactions to perform, you must ensure that you have an established connection at the start of each new transaction. Sometimes, due to severe errors the connection can be lost and therefore will not be re-used in later transactions. Therefore for good connection handling process you should use the function OraFormsIsConnected. This function can be used to query if a connection has already been established previously in the script, and should be called at the start of each new transaction. For full details on how to create such an example, please see Advanced Concepts book Load testing Oracle forms. Memory footprint The Oracle Forms replay engine uses SilkPerformer Java Framework to send and receive the Oracle Forms messages. Therefore each Vuser (PerfRun) requires additional memory. The reason for this is that the Java Runtime must be hosted once per runtime process, not once per Vuser executed in the runtime. So this means that for every PerfRun the JVM has to be loaded, although the JVM has to be loaded it does not mean that this is limited to one Vuser pre PerfRun. You can host multiple Vusers Per PerfRun process, the setting to change the amount of Vusers per PerfRun can be located in the System Settings at Settings | System Settings | Workbench | Control | Virtual Users Virtual users pre process The Java Footprint of the Java Runtime process will depend on the JDK that is used for replay. But, on average 10 MB is required to host a Java Runtime. But, the overall footprint will be dependant on the following factors: Length of the Oracle Forms script Number of hosted Oracle Forms controls Oracle Forms log level selected The TrueLog options you have set.

To determine the footprint and calculate an average space required for scalability please see the link: How can I work out the virtual memory each Vuser will use in my load test? Note: The above resolution only applied to 10Vuser per PerfRun, so depending on your setup the number of Vusers Per Process will need to be adjusted depending on how many Vusers you wish each PerfRun to host. Avoid Using JDK 1.2 The development group; have informed our users to avoid using JDK version 1.2. The reason for this is that this version is not optimal for performance reasons and is not a stable java runtime and should be avoided if possible. However as Technical support Engineers we should always recommend our customers to always install and use the latest versions. The latest development kits are available from the URL below: http://www.sun.com/download/index.jsp?cat=Application%20Development&tab=3&subcat=S DKs%20(Software%20Development%20Kits) Increasing the JVM memory The Java Virtual Machine you use can be configured to use minimum and maximum heap sizes. These settings can be employed when out of memory exceptions errors are seen. This may be useful during the recording process, as recording of Oracle Forms is a very resource

intensive process and can be influenced by the selected log level and length of transactions within the script. If you encounter memory problems on record of the Oracle forms application, please see Advanced Concepts book Load testing Oracle forms for full details on how to configure the JVM heap sizes. Disable the JVM JIT Compiler The development team, have informed customers to disable the Java JIT Compiler option in the Java runtime settings, They have informed customers to disable this option if they have browser crashes. Full details on how to disable this setting can be found in the Advanced Concepts book Load testing Oracle forms or see the resolution at http://support.segue.com/kbshow.php?q=17073 Recording oracle forms on Sockets level If the Oracle Forms server you are testing is using sockets then to accurately record the Oracle Forms script you must suppress the traffic the Forms server generates whilst communicating with the Applet. To suppress this traffic and ensure you do not get a mixed TCP/IP and HTTP/Oracle Forms script please follow the steps listed below. Setting | System Settings | Recorder | Proxies | Socks

In the suppressed recording port field, enter the port that your Oracle Forms application uses for communication with the applet. As shown in the image below.

Note: If you fail to suppress the port, SilkPerformer will record on both the Oracle Forms level and the TCP/IP level. This will generate a script with mixed OraForms and WebTcp calls.

After following the steps above you may run into some recording difficulties, these can occur due to SilkPerformer having to "listen" on both transport channels: HTTP/ HTTPS and Sockets. Some applications that operate on the Socket layer have been known to crash Internet Explorer while both channels are being recorded. As a by product of this known issue SilkPerformer allows us to specify the transport channel that is of interest to us when recording Oracle Forms applications. To set the correct application profile in this instance please follows the steps below: - Settings | System Settings | Recorder | Application Profile - Select Internet Explorer and click on Edit - For the Protocol Selection please ensure you select Web and enable the option Oracle Forms 6i on Socket. Your Application Profile will now look as shown below:

As a result of settings the above Application Profile you may notice that the Java Settings option is now enabled. This will be need to be configured and set to the protocol you wish to record. The Java Settings button will give you three options as shown below:

The recording methods above can be summarized as the following: Java Virtual Machine hooking This option is used when you need to hook into a JVM. This option should be the default when you need to record Oracle Forms on Socket level. Network only This option is used to only hook (catch) class and jar files that are downloaded via HTTP. This option was the default used in early versions of SilkPerformer when recording against Jolt and Jacada applications. Manual This option should only be selected if you have manually prepared a startup script to record your Java application. Note: Johannes at development have informed us that we should not select the option JVM hooking, when using a Microsoft JVM or a IBM JVM. I presume this is why we use this option to hook and record the Oracle Forms JVM when recording at Forms Socket level Files to collect before logging Oracle Forms issue to Development When troubleshooting Oracle Forms issues within support, we should always get the following: Full Project, This can be exported via the menu option: Help | Email project to Technical Support Please ensure that the customer enabled the option to include results file from all tests Customer should always Record and Replay with debug log-level set. To set this option, go to Settings | Active Profile | Oracle Forms | Logging | Settings | Log Level Support should also ensure that we get the customer to send the console output of the java console. We should get this output when the customer is launching an Oracle Forms application. - Support should request the exact information about the Oracle Forms versions the customer is using. We should request exact version, build details as patch levels that have been applied. The following checklist should be followed when requesting the details we need for logging to development: - Exact Server and Client SW Versions - JInitiator Version - Oracle Forms Server Version + Patch Version - Client Jar Files, such as F90all.jar, f60all.jar - Full project file with all results and appropraite logging set (as mentioned above) - Java Console output

For a more in-depth description of the files we need to collect before logging to development please see the resolution: http://support.segue.com/kbshow.php?q=16869

The last section of this paper will look at the resolutions we have in-house at support and some links are enclosed that will give the readers more insight into the architecture and technical details of Oracle forms. RESOLUTIONS WITHIN SUPPORT What factors can cause high memory utilization when running Oracle Forms scripts and what are the recommended settings? http://support.segue.com/kbshow.php?q=19047 What causes the warning : OraFormsSetInt(OraForms: 24 - Profile setting INITIAL_VERSION overridden by function OraFormsSetInt) http://support.segue.com/kbshow.php?q=18947 Why do I get the Oracle forms replay warning: OraFormsSetConnectMode(OraForms: 23 - OraFormsSetConnectMode overrides the profile's connection setting) http://support.segue.com/kbshow.php?q=18937 Versions of Oracle Forms supported by SilkPerformer http://support.segue.com/kbshow.php?q=14153 What is Oracle's JInitiator and why is it recommended when using Oracle Forms? http://support.segue.com/kbshow.php?q=17069 Can I use the Jinitiator runtime when replaying my Oracle Forms script in SilkPerformer? http://support.segue.com/kbshow.php?q=19265

When recording my Oracle Forms application, why does my browser hang? http://support.segue.com/kbshow.php?q=19486 Why do I receive a 'Class Definition Not Found' error while recording against Oracle Forms 6i? http://support.segue.com/kbshow.php?q=19247 Why does TrueLog Explorer crash when Animated mode is chosen during an Oracle Forms Try-Script? http://support.segue.com/kbshow.php?q=19190 Why Do I get the error: OraFormsConnect(OraForms: 21 - Severe Runtime Error, class java.net.ConnectException connect: Address is invalid on local machine, or port is not valid on remote machine)? http://support.segue.com/kbshow.php?q=18965 When recording an Oracle Forms 6i based application why do I see the error 'Can't start JVM v1.1, reason: Unable to initialize threads..' in the script http://support.segue.com/kbshow.php?q=18907 How do I resolve the error "OraFormsSetWindow(OraForms: 5 - Handler not found, ......)" that occurs when I replay my Oracle forms script? http://support.segue.com/kbshow.php?q=18550

Why do I get the error: OraFormsConnect(OraForms: 26 - Handler already destroyed or not created yet, Warning: cannot find handler with id: xx when replaying my Oracle forms script? http://support.segue.com/kbshow.php?q=18392

How can I identify the client jar files that my Oracle forms application uses? http://support.segue.com/kbshow.php?q=17446 When I first browse to my Oracle forms server url why does the page take a long time to load? http://support.segue.com/kbshow.php?q=17445

ORACLE FORMS LINKS Oracle Forms 10g http://www.oracle.com/technology/products/forms/techlisting10g.html Oracle9i Forms Technical Information http://www.oracle.com/technology/products/forms/techlisting9i.html Oracle Forms Release 6i http://www.oracle.com/technology/products/forms/techlisting.html Oracle Technical Network http://otn.oracle.com