Terraform


Terraform installation via wget

ubuntu@kubernetes-worker:~/terraform-project/terrformcfg/base/basevaribale$ wget https://releases.hashicorp.com/terraform/0.8.0/terraform_0.8.0_linux_amd64.zip

Then unzip the directory and update in bash profile.

you can strat with terraform version command to check version

ubuntu@kubernetes-worker:~/terraform-project/terrformcfg/base/basevaribale$ terraform version
Terraform v0.12.21



Installing via configuration management
There are also configuration management resources available for installing Terraform.
You can find:
• A Puppet module for Terraform.
• A Chef cookbook for Terraform.
• An Ansible role for Terraform.
• A Terraform Docker container.
Getting started


Terraform  (init/apply/plan/validate)
https://www.terraform.io/docs/providers/aws/r/instance.html

ubuntu@kubernetes-worker:~/terraform-project/terrformcfg/base$ ################INITILIZATION OF AWS IN TERRAFORM###################
ubuntu@kubernetes-worker:~/terraform-project/terrformcfg/base$ cat base.tf
provider "aws" {
region     = "ap-south-1"
access_key = "AKIAJCQWLV3LYUWPIQVQ"
secret_key = "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"
}

resource "aws_instance" "lava" {
  ami           = "ami-0d9462a653c34dab7"
  instance_type = "t2.micro"
  key_name      = "TEST"
}

resource "aws_eip" "lavaeip" {

instance = "aws_instance.lava.id"

  vpc = true


}




ubuntu@kubernetes-worker:~/terraform-project/terrformcfg/base$ terraform init

Initializing the backend...

Initializing provider plugins...

The following providers do not have any version constraints in configuration,
so the latest version was installed.

To prevent automatic upgrades to new major versions that may contain breaking
changes, it is recommended to add version = "..." constraints to the
corresponding provider blocks in configuration, with the constraint strings
suggested below.

* provider.aws: version = "~> 2.50"

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.
ubuntu@kubernetes-worker:~/terraform-project/terrformcfg/base$ terraform validate
Success! The configuration is valid.

ubuntu@kubernetes-worker:~/terraform-project/terrformcfg/base$ terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.


------------------------------------------------------------------------

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # aws_eip.lavaeip will be created
  + resource "aws_eip" "lavaeip" {
      + allocation_id     = (known after apply)
      + association_id    = (known after apply)
      + domain            = (known after apply)
      + id                = (known after apply)
      + instance          = "aws_instance.lava.id"
      + network_interface = (known after apply)
      + private_dns       = (known after apply)
      + private_ip        = (known after apply)
      + public_dns        = (known after apply)
      + public_ip         = (known after apply)
      + public_ipv4_pool  = (known after apply)
      + vpc               = true
    }

  # aws_instance.lava will be created
  + resource "aws_instance" "lava" {
      + ami                          = "ami-0d9462a653c34dab7"
      + arn                          = (known after apply)
      + associate_public_ip_address  = (known after apply)
      + availability_zone            = (known after apply)
      + cpu_core_count               = (known after apply)
      + cpu_threads_per_core         = (known after apply)
      + get_password_data            = false
      + host_id                      = (known after apply)
      + id                           = (known after apply)
      + instance_state               = (known after apply)
      + instance_type                = "t2.micro"
      + ipv6_address_count           = (known after apply)
      + ipv6_addresses               = (known after apply)
      + key_name                     = "TEST"
      + network_interface_id         = (known after apply)
      + password_data                = (known after apply)
      + placement_group              = (known after apply)
      + primary_network_interface_id = (known after apply)
      + private_dns                  = (known after apply)
      + private_ip                   = (known after apply)
      + public_dns                   = (known after apply)
      + public_ip                    = (known after apply)
      + security_groups              = (known after apply)
      + source_dest_check            = true
      + subnet_id                    = (known after apply)
      + tenancy                      = (known after apply)
      + volume_tags                  = (known after apply)
      + vpc_security_group_ids       = (known after apply)

      + ebs_block_device {
          + delete_on_termination = (known after apply)
          + device_name           = (known after apply)
          + encrypted             = (known after apply)
          + iops                  = (known after apply)
          + kms_key_id            = (known after apply)
          + snapshot_id           = (known after apply)
          + volume_id             = (known after apply)
          + volume_size           = (known after apply)
          + volume_type           = (known after apply)
        }

      + ephemeral_block_device {
          + device_name  = (known after apply)
          + no_device    = (known after apply)
          + virtual_name = (known after apply)
        }

      + network_interface {
          + delete_on_termination = (known after apply)
          + device_index          = (known after apply)
          + network_interface_id  = (known after apply)
        }

      + root_block_device {
          + delete_on_termination = (known after apply)
          + encrypted             = (known after apply)
          + iops                  = (known after apply)
          + kms_key_id            = (known after apply)
          + volume_id             = (known after apply)
          + volume_size           = (known after apply)
          + volume_type           = (known after apply)
        }
    }

Plan: 2 to add, 0 to change, 0 to destroy.

------------------------------------------------------------------------

Note: You didn't specify an "-out" parameter to save this plan, so Terraform
can't guarantee that exactly these actions will be performed if
"terraform apply" is subsequently run.

ubuntu@kubernetes-worker:~/terraform-project/terrformcfg/base$ terraform plan -out lava.plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.


------------------------------------------------------------------------

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # aws_eip.lavaeip will be created
  + resource "aws_eip" "lavaeip" {
      + allocation_id     = (known after apply)
      + association_id    = (known after apply)
      + domain            = (known after apply)
      + id                = (known after apply)
      + instance          = "aws_instance.lava.id"
      + network_interface = (known after apply)
      + private_dns       = (known after apply)
      + private_ip        = (known after apply)
      + public_dns        = (known after apply)
      + public_ip         = (known after apply)
      + public_ipv4_pool  = (known after apply)
      + vpc               = true
    }

  # aws_instance.lava will be created
  + resource "aws_instance" "lava" {
      + ami                          = "ami-0d9462a653c34dab7"
      + arn                          = (known after apply)
      + associate_public_ip_address  = (known after apply)
      + availability_zone            = (known after apply)
      + cpu_core_count               = (known after apply)
      + cpu_threads_per_core         = (known after apply)
      + get_password_data            = false
      + host_id                      = (known after apply)
      + id                           = (known after apply)
      + instance_state               = (known after apply)
      + instance_type                = "t2.micro"
      + ipv6_address_count           = (known after apply)
      + ipv6_addresses               = (known after apply)
      + key_name                     = "TEST"
      + network_interface_id         = (known after apply)
      + password_data                = (known after apply)
      + placement_group              = (known after apply)
      + primary_network_interface_id = (known after apply)
      + private_dns                  = (known after apply)
      + private_ip                   = (known after apply)
      + public_dns                   = (known after apply)
      + public_ip                    = (known after apply)
      + security_groups              = (known after apply)
      + source_dest_check            = true
      + subnet_id                    = (known after apply)
      + tenancy                      = (known after apply)
      + volume_tags                  = (known after apply)
      + vpc_security_group_ids       = (known after apply)

      + ebs_block_device {
          + delete_on_termination = (known after apply)
          + device_name           = (known after apply)
          + encrypted             = (known after apply)
          + iops                  = (known after apply)
          + kms_key_id            = (known after apply)
          + snapshot_id           = (known after apply)
          + volume_id             = (known after apply)
          + volume_size           = (known after apply)
          + volume_type           = (known after apply)
        }

      + ephemeral_block_device {
          + device_name  = (known after apply)
          + no_device    = (known after apply)
          + virtual_name = (known after apply)
        }

      + network_interface {
          + delete_on_termination = (known after apply)
          + device_index          = (known after apply)
          + network_interface_id  = (known after apply)
        }

      + root_block_device {
          + delete_on_termination = (known after apply)
          + encrypted             = (known after apply)
          + iops                  = (known after apply)
          + kms_key_id            = (known after apply)
          + volume_id             = (known after apply)
          + volume_size           = (known after apply)
          + volume_type           = (known after apply)
        }
    }

Plan: 2 to add, 0 to change, 0 to destroy.

------------------------------------------------------------------------

This plan was saved to: lava.plan

To perform exactly these actions, run the following command to apply:
    terraform apply "lava.plan"

ubuntu@kubernetes-worker:~/terraform-project/terrformcfg/base$


ubuntu@kubernetes-worker:~/terraform-project/terrformcfg/base/basevaribale$ ls -ltr
total 20
-rw-rw-r-- 1 ubuntu ubuntu 2044 Feb 29 10:00 basevar.plan
-rw-rw-r-- 1 ubuntu ubuntu 2876 Feb 29 10:15 terraform.tfstate.backup
-rw-rw-r-- 1 ubuntu ubuntu  157 Feb 29 10:27 terraform.tfstate
-rw-rw-r-- 1 ubuntu ubuntu  540 Feb 29 10:30 var.tf
-rw-rw-r-- 1 ubuntu ubuntu  206 Feb 29 10:49 basevar.tf


***terraform.tfstate file will be take backup automatically before we execute terraform apply***

To find out the terraform version?
ubuntu@kubernetes-worker:~/terraform-project/terrformcfg/base/basevaribale$ terraform version
Terraform v0.12.21
+ provider.aws v2.51.0

Set path in linux/ubuntu

ubuntu@kubernetes-worker:~$ cat .bash_profile
export PATH=${PATH}:/home/ubuntu/terraform-project

ubuntu@kubernetes-worker:~$


****Variable's Declaration method***
ubuntu@kubernetes-worker:~/terraform-project/terrformcfg/base/basevaribale$ cat basevar.tf
provider "aws" {
access_key = var.access_key
secret_key = var.secret_key
region = var.region
}
resource "aws_instance" "TESTING" {
ami = var.ami
instance_type=var.instype
security_groups = var.secgroup
}

*****Create variable file with extension of Tf***
Note:For default type of variables no need to provide type parameter seprately.
ubuntu@kubernetes-worker:~/terraform-project/terrformcfg/base/basevaribale$ cat var.tf
variable "access_key" {
description = "The AWS access key."
default="AKIAJCQWLV3LYUWPIQVQ"
}
variable "secret_key" {
description = "The AWS secret key."
default = "InkKtKGUkRKMD4eDMaXPcfNK1h6NpPu+3hwq8w6L"
}
variable "region" {
description = "The AWS region."
default = "ap-south-1"
}
variable "ami" {
description = " the required ami "
default = "ami-0d9462a653c34dab7"
}
variable "instype" {
description = " select the instancetype"
default = "t2.micro"
}
variable "secgroup" {
description = "select the tuflee secgroup"   
type = string  ###this will ask parameter value in run time####
}

Type constraint:

it is used restrict all unwanted values and allows the required value from variable which is declared in var.tf




Type constraints are created from a mixture of type keywords and type constructors. The supported type keywords are:
The type constructors allow you to specify complex types such as collections:




The name of a variable can be any valid identifier except the following:

AES S3 bucket integrate as mount in EC2 instance

NOTE:https://howto.lintel.in/how-to-mount-aws-s3-bucket-on-linux/

After creation Ec2 instance

yum -y install automake fuse fuse-devel gcc-c++ libcurl-devel libxml2-devel make openssl-dev
el


sudo yum install git

Complete!
[root@ip-172-31-41-86 ~]# git clone https://github.com/s3fs-fuse/s3fs-fuse.git
Cloning into 's3fs-fuse'...
remote: Enumerating objects: 37, done.
remote: Counting objects: 100% (37/37), done.
remote: Compressing objects: 100% (31/31), done.
remote: Total 5876 (delta 16), reused 17 (delta 6), pack-reused 5839
Receiving objects: 100% (5876/5876), 3.53 MiB | 2.86 MiB/s, done.
Resolving deltas: 100% (4067/4067), done.
[root@ip-172-31-41-86 ~]# ^C
[root@ip-172-31-41-86 ~]# ls
s3fs-fuse
[root@ip-172-31-41-86 ~]# cd s*
[root@ip-172-31-41-86 s3fs-fuse]# ls
AUTHORS  autogen.sh  ChangeLog  COMPILATION.md  configure.ac  COPYING  doc  INSTALL  Makefile.am  README.md  src  test
[root@ip-172-31-41-86 s3fs-fuse]#  ./autogen.sh
--- Make commit hash file -------
--- Finished commit hash file ---
--- Start autotools -------------
configure.ac:26: installing './config.guess'
configure.ac:26: installing './config.sub'
configure.ac:27: installing './install-sh'
configure.ac:27: installing './missing'
src/Makefile.am: installing './depcomp'
parallel-tests: installing './test-driver'
--- Finished autotools ----------
[root@ip-172-31-41-86 s3fs-fuse]# ./configure
checking for sys/xattr.h... yes
checking attr/xattr.h usability... no
checking attr/xattr.h presence... no
checking for attr/xattr.h... no
checking sys/extattr.h usability... no
checking sys/extattr.h presence... no
checking for sys/extattr.h... no
checking s3fs build with nettle(GnuTLS)... no
checking s3fs build with OpenSSL... no
checking s3fs build with GnuTLS... no
checking s3fs build with NSS... no
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for common_lib_checking... yes
checking compile s3fs with... OpenSSL
checking for DEPS... no
configure: error: Package requirements (fuse >= 2.8.4 libcurl >= 7.0 libxml-2.0 >= 2.6 libcrypto >= 0.9 ) were not met:

No package 'libcrypto' found

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables DEPS_CFLAGS
and DEPS_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
[root@ip-172-31-41-86 s3fs-fuse]# make**FAILED**

mkdir -p /var/s3fs-demo-fs
[root@ip-172-31-41-86 s3fs-fuse]#
[root@ip-172-31-41-86 s3fs-fuse]# aws s3 mb s3://s3fs-demobk
make_bucket: s3fs-demobk
[root@ip-172-31-41-86 s3fs-fuse]# s3fs s3fs-demobk /var/s3fs-demo-fs -o iam_role-ec2t
os3
-bash: s3fs: command not found
[root@ip-172-31-41-86 s3fs-fuse]# bash
[root@ip-172-31-41-86 s3fs-fuse]# s3fs
bash: s3fs: command not found

###FIX S3FS NOT FOUND###
yum install gcc libstdc++-devel gcc-c++ curl-devel libxml2-devel openssl-devel mailcap fuse fuse-devel
wget http://s3fs.googlecode.com/files/s3fs-1.61.tar.gz
tar xvzf s3fs-1.61.tar.gz
cd s3fs-1.61/
./configure --prefix=/usr
make
make install
vim  /etc/passwd-s3fs
chmod 640 /etc/passwd-s3fs
s3fs yourBucketNameHere /mnt


s3fs s3fs-demobk /var/s3fs-demo-fs -o iam_role_ec2tos3

to fix passwd-s3fs issue need to enter the accessid and key id


Access Key ID:AKIAJVTBI7PNBULL4XSA
Secret Access Key:OFKq1LcUkuBQ0BYF9oenCkZ/+EoQ8SrScwlD6Y2i

AKIAJVTBI7PNBULL4XSA:OFKq1LcUkuBQ0BYF9oenCkZ/+EoQ8SrScwlD6Y2i

s3fs s3fs-demobk /var/s3fs-demo-fs -o asswd_file=/etc/passwd-s3fs

syntax --->s3fs mybucketname /path/to/mountpoint -o passwd_file=/etc/passwd-s3fs


SSO configuration



Ø  Take Backup of httpd.config file
Ø  place the osso.conf file in any location of the server
Ø  modify httpd.config file by adding osso.conf file and required consoles needs to be added to autantication type as sso in if module

example
 RewriteEngine On
    RewriteOptions inherit
 LoadModule osso_module "/p01/pnfmwp01/ren/soa/fmwhm/oraohs/ohs/modules/mod_osso.so"

 <IfModule osso_module>
 OssoIpCheck off
 OssoIdleTimeout off
 OssoConfigFile "/p01/pnfmwp01/ren/soa/admin/osso/soa_osso/osso.conf"
 OssoSecureCookies off

 <Location /console>
 require valid-user
 AuthType Osso
 </Location>

 <Location /em>
 require valid-user
 AuthType Osso
 </Location>

 <Location /consolehelp>
 require valid-user
 AuthType Osso
 </Location>

 <Location /wsm-pm>
 require valid-user
 AuthType Osso
 </Location>

 #<Location /soa-infra>
 #require valid-user
 #AuthType Osso
 #</Location>

 # SOA inspection.wsil
 <Location /inspection.wsil>
 require valid-user
 AuthType Osso
 </Location>
 # Worklist

 #Adam Advised to comment out done by rajesh
 #<Location /integration>
 #require valid-user
 #AuthType Osso
 #</Location>


 <Location /b2bconsole>
 require valid-user
 AuthType Osso
 </Location>

 # SOA composer application
 <Location /soa/composer>
 require valid-user
 AuthType Osso
 </Location>

 <Location /bpm/composer>
 require valid-user
 AuthType Osso
 </Location>

 # BPM
 <Location /bpm/workspace>
 require valid-user
 AuthType Osso
 </Location>


 <Location /OracleBAM >
 require valid-user
 AuthType Osso
 </Location>

 #Adam asked to comment out done by Rajesh
 #<Location /OracleBAMWS >
 #require valid-user
 #AuthType Osso
 #</Location>

 # Commented for Oracle DI agent

 # ODI Agent
 #<Location /odiconsole>
 #require valid-user
 #AuthType Osso
 #</Location>


 #ODI Explorere
 #<Location /odirepex>
 #require valid-user
 #AuthType Osso
 #</Location>

 #ODI Webservices
 #<Location /oracledisdkws>
 #require valid-user
 #AuthType Osso
 #</Location>


 Create service Provider
Ø  Create Service Provider
o   Home >Summary of Security Realms >myrealm >Providers


Shutting down database abnormally --- shut abort what happens inside

An instance(crash) failure occurs when your database isn’t able to shutdown normally.When this happens, your datafiles could be in an inconsistent state meaning they may not contain all committed changes and may contain uncommitted changes. Instance failures occur when the isntance terminates abnormally. A sudden power failure or a shutdown abort are two common causes of isntance failure.
Oracle uses crash recovery to return the database to a consistent committed state after an instance failure. Crash recovery guarntees that when your database is opened, it will contain only transactions that were committted before the instance failure occured. Oracle system monitor will automatically detect whether crash recovery is required.
Crash recovery has two pahses : rollforward and rollback
The system monitor will first roll forward and apply to the datafiles any transactions in the online redo files that occured after the most recent checkpoint. Crash Recovery uses redo information found in the online redo log files onlu . After rolling forward, Oracle will rollback any of those transactions that were never committed. Oracle uses information stored in the undo segments to rollback (undo) any uncommitted transactions.
When you start your database, Oracle uses the SCN information in the control files and datafiles headers to determin which one of the following will occur.
Starting up normally.
Performing crash Recovery
Determining that media reocvery is required.
On start up , Oracle check the instance thread status to determine whether crash recover is required . When the database is open for normal operations ,the thread status is OPEN. When Oracle us shut down normally , a checkpoint takes place and the instance thread status is set to CLOSED.
when your instance abnormally terminates the thread status remains OPEN because Oracle didn’t get a chance to upodate teh status to CLOSED.
On startup , When Oracle detects that an instance thread was abnormally left open, the system monitor process will automatically perform crash recovery.
The below query , it will usefull to find out whether crash recovery is required.
select a.thread#,b.open_mode,a.status,
CASE
WHEN((b.open_mode=’MOUNTED’) AND (a.status=’OPEN’)) THEN ‘Crash Recovery req.’
WHEN((b.open_mode=’MOUNTED’) AND (a.status=’CLOSED’)) THEN ‘No Crash Recovery Req.’
WHEN((b.open_mode=’READ WRITE’) AND (a.status=’OPEN’)) THEN ‘Instance already open’
ELSE ‘huh?’
END STATUS
FROM v$thread a,
v$database b,
v$instance c
where a.thread#=c.thread#;

Forms Servlet mode vs Socket mode

how can we check forms are in socket mode or servelet mode?
[appogfh1@ogerpl3851dv orpogfh1_ogerpl3851dv]$ grep connectMode $FORMS60_WEB_CONFIG_FILE
connectMode=socket

also from formsweb.cfg file also we can check.

 

Oracle Forms can be run in either servlet mode or socket mode. 

§  Oracle Applications 11i is based on Forms 6i and is configured to run in socket mode by default. 

§  Oracle Applications 12i is based on Forms 10g and is configured to run in servlet mode by default.  


What is Forms Socket Mode?The connection from the desktop client to the Forms Listener process was accomplished using a direct socket connection. 

§  The direct socket connection mode was suitable for companies providing thin client access to Forms applications within their corporate local area networks.

§  For the direct socket connection mode, the client had to be able to see the server and had to have permission to establish a direct network connection.

§  Although the direct socket connection mode is perfectly suited for deployments within a company’s internal network, it’s not the best choice for application deployment via unsecured network paths via the Internet.

§  A company connected to the Internet typically employs a strict policy defining the types of network connections that can be made by Internet clients to secure corporate networks.

Oracle Applications Release12 by default configures Forms 10g stack in servlet mode, as this is the preferred and recommended deployment model for forms on the web.  In this mode a java servlet called the Forms Listener servlet manages the communication between the Forms Java Client and the Oracle AS Forms Services.

The Forms Listener Servlet communicates through the HTTP server port and does not need extra ports to handle the communication between the client and the Oracle Application Server Forms Services.

The Forms Servlet architecture is also compatible with web applications industry standards and supports different advanced network configurations such as Load balancing effortlessly.

Although Forms Servlet is the preferred deployment method, there may be circumstances where customers need to switch from Forms Servlet mode to Forms Socket mode, which allows desktop clients to access the Forms Server directly.

https://img1.blogblog.com/img/video_object.png

REPORT THIS AD

 

This may be required in the following situations:

§  Customers’ network topology is multimode and the Forms Services are configured on a node different from the node on which Web services (Web Entry Point and Web Applications) are configured.

§  Customers constrained by network bandwidth, or machine resources may consider socket mode as an alternative to improve performance.

§  To reduce network traffic. The servlet mode uses http protocol on each transaction between a client and the Forms Server requiring the exchange of cookies and http headers which increases network traffic.

§  To reduce consumption of resources use by the JVMS needed in servlet mode architecture.

 Socket Mode Advantages

1.     Uses up to 40% less bandwidth than Forms servlet mode.  This may be perceived by Wide Area Network (WAN) users as causing slower responsiveness, depending upon network latency.

2.     Uses fewer application-tier JVM resources than servlet mode, due to fewer TCP turns and lack of overhead associated with HTTP POST handling.

Enabling Forms Socket Mode
Execute the following steps to switch from Forms Servlet mode to Forms Socket mode:

1.     Source the environment on the application tier.

2.     Stop all the application tier services using adstpall.sh

3.     Run the following command to enable Forms Socket Mode:

$FND_TOP/bin/txkrun.pl -script=ChangeFormsMode \
[-contextfile=<CONTEXT_FILE>] \
-mode=socket \
[-port=<Forms port number>] \
-runautoconfig=<No or Yes> \
-appspass=<APPS password>

Parameter

Description

-contextfile

Full path to application tier context file, using the syntax:On UNIX:$INST_TOP/appl/admin/<CONTEXT_NAME>.xml

-mode

servlet – to enable Forms Servlet mode. This is the default value.socket – to enable Forms Socket mode

-port

Port number used to run Forms in socket mode. The default port number is 9095.A port number is not needed if servlet mode is used.

-runautoconfig

Specify whether AutoConfig should be run after changing the forms mode. Possible values are:No – Do not run AutoConfig after enabling Forms servlet/socket mode. This is the recommended value.Yes – Run AutoConfig after enabling Forms servlet/socket mode.

-appspass

Password for the applications user. Required only if -runautoconfig=Yes.

 4. If Autoconfig was not automatically executed as part of the preceding step, then run AutoConfig on the application tier:

On UNIX:

$INST_TOP/admin/scripts/adautocfg.sh

5. Start all the application tier services:

On UNIX:

$INST_TOP/admin/scripts/adstrtal.sh

6.Check whether Forms Server is running:

On UNIX:

$INST_TOP/admin/scripts/adformsrvctl.sh status

1.     Log in to Oracle Applications and  launch a Forms-based application.

2.     Open the Sun Java Console (from Tools Menu in Internet Explorer).

3.     Check whether the “mode” directive displayed in Sun Java Console when launching forms-based applications is set to socket.

4.     The direct launch URL for Forms Socket Mode is:

<web_protocol>://<web_host>.<web_domain>:<web_port>/OA_HTML/frmservlet

 What is Forms Servlet Mode?

The Forms Listener Servlet is a Java servlet that delivers the ability to run Oracle Forms applications over HTTP and HTTPS connections. It manages the creation of a Forms Server Runtime process for each client, as well as network communications between the client and its associated Forms Server Runtime process.

The desktop client sends HTTP requests and receives HTTP responses from the web server. The HTTP Listener on the web server acts as the network endpoint for the client, keeping other servers and ports from being exposed at the firewall. 

Servlet Mode Advantages

1.     HTTP and HTTPS traffic is easily recognizable by routers, while socket mode communications is generally considered suspect and treated on an exception basis. 

2.     Existing networking hardware can be used to support basic functions such as load-balancing and packet encryption for network transit.

3.     More resilient to network and firewall reconfigurations.

4.     More robust: servlet connections can be reestablished if network connections drop unexpectedly for Forms, Framework, and JSP-based pages.

5.     Is the only supported method for generic Oracle Forms customers, and therefore is more thoroughly tested by the Forms and E-Business Suite product groups.

6.     Performance traffic can be monitored via tools like Oracle Real User Experience Insight (RUEI).

7.     Socket mode is not supported on Windows-based server platforms.

Enabling Forms Servlet Mode

Carry out these steps to reenable Forms Servlet mode if Socket Mode is no longer required:

1.Source the environment on the application tier.

2. Stop all the application tier services:

On UNIX:

$INST_TOP/admin/scripts/adstpall.sh

3. Run the following script to disable Forms Socket Mode and re-enable Forms Servlet Mode:

$FND_TOP/bin/txkrun.pl -script=ChangeFormsMode \
[-contextfile=<CONTEXT_FILE>] \
[-mode=servlet] \
-runautoconfig=<No or Yes> \
-appspass=<APPS password>

Parameter

Description

-contextfile

Full path to application tier context file, using the syntax:On UNIX:$INST_TOP/appl/admin/<CONTEXT_NAME>.xml

-mode

servlet – to enable Forms Servlet mode. This is the default value.socket – to enable Forms Socket mode

-port

Port number used to run Forms in socket mode. The default port number is 9095.A port number is not needed if servlet mode is used.

-runautoconfig

Specify whether AutoConfig should be run after changing the forms mode. Possible values are:No – Do not run AutoConfig after enabling Forms servlet/socket mode. This is the recommended value.Yes – Run AutoConfig after enabling Forms servlet/socket mode.

-appspass

Password for the applications user. Required only if -runautoconfig=Yes.

 

4.If Autoconfig was not automatically executed as part of the preceding step, then run AutoConfig on the application tier:

On UNIX:

$INST_TOP/admin/scripts/adautocfg.sh

5. Start all the application tier services:

On UNIX:

$INST_TOP/admin/scripts/adstrtal.sh

1.     Log in to Oracle Applications and  launch a Forms-based application.

2.     Open the Sun Java Console (from Tools Menu in Internet Explorer).

3.     Check whether the “mode” directive displayed in Sun Java Console when launching forms-based applications, is set to http,native

4.     Direct Forms Servlet Launch is:

web_protocol>://<web_host>.<web_domain>:<web_port>/forms/frmservlet

Step 4.1: Manually Starting Forms Server

On UNIX:

$INST_TOP/admin/scripts/adformsrvctl.sh start

Step 4.2: Manually Stopping Forms Server

On UNIX:

$INST_TOP/admin/scripts/adformsrvctl.sh stop

Step 4.3: Checking Status of Forms Server

On UNIX:

$INST_TOP/admin/scripts/adformsrvctl.sh status

Switching Apps Deployments between Modes

Due to its numerous advantages, Forms servlet mode is the preferred and recommended deployment model for Forms on the web. 

There may be circumstances where you need to switch between the default Forms modes.  You might wish to switch your Oracle E-Business Suite Release 12 environment to socket mode to improve performance or reduce network load.  You might wish to switch your Apps 11i environment to servlet mode as part of your rollout to external web-based end-users outside of your organization.

If you’re running Apps 11i and would like to switch to servlet mode, see:

§  Using Forms Listener Servlet with Oracle Applications 11i (Note 201340.1)

If you’re running Apps 12 and would like to switch to socket mode, see:

§  Using Forms Socket Mode in Oracle Applications Release 12 (Note 384241.1)