Kony Server Installation on Linux Manual WebLogic

(1)

Installation on Linux – Manual

– WebLogic

Kony Platform

Release 5

Document Relevance and Accuracy

This document is considered relevant to the Release stated on this title page and the document version stated on the Revision History page. Remember to always view and download the latest document version relevant to the software release you are using.

(2)

December, 2013

This document contains information proprietary to Kony, Inc., is bound by the Kony license agreements and may not be used except in the context of understanding the use and methods of Kony software without prior, express, written permission. Kony and Empowering

Everywhere are trademarks of Kony, Inc. Microsoft, the Microsoft logo, Internet Explorer, Windows and Windows Vista are registered trademarks of Microsoft Corporation. Apple, the Apple logo, iTunes, iPhone, iPad, OS X, Objective-C, Safari and Xcode are registered

trademarks of Apple, Inc.. Google, the Google logo, Android and the Android logo are registered trademarks of Google, Inc. Chrome is a trademark of Google, Inc. BlackBerry, PlayBook, Research in Motion, and RIM are registered trademarks of BlackBerry. All other terms, trademarks or service marks mentioned in this document have been capitalized and are to be considered the property of their respective owners.

(3)

Revision History

Date Document

Version Description of Modifications/Release 08/31/2012 5.0 Document Release for Kony 5.0.

04/26/2013 5.1 Updated the document with MS SQL, DB2, My SQL, Logdaemon configurations.

06/04/2013 5.2 Updated the document with Mobile Web JS configurations. 08/26/2013 5.3 Updated the document with Configure License Datasource as

(4)

1. Overview

Kony Platform provides an integrated approach to mobile application design, development and management. This facilitates mobile applications development independent of any specific device, and delivery in different formats that run on all the major device platforms.

The Kony Platform consists of three main components:

n Kony Studio:Designs and develops mobile applications.

n Kony Server:Provides server side functionality for the applications, common data integration and device support services

n Client RuntimeComponent for each major device platform that enables the same mobile application to execute directly on the device.

1.1 Kony Server

The application functionality developed and generated by the Kony Studio is enabled and delivered using Kony Server. The SMS and Mobile Webchannels are hosted on Kony Server and the Native Apps binaries are deployed to the server, to be downloaded by the device.

Kony Server has the following features:

n A sophisticated device database that enables it to detect and deliver the appropriate binary to a requesting device.

n Inbuilt backend data services integration capability, with out-of-the-box support for Web Services, XML feeds and HTML extraction.

n Integration with optional third party connector libraries that offer access to a large number of ERP, database and legacy systems.

n Built in usage tracking and analysis capability that provides a wide range of reports on system and application use.

1.2 Server Installation Guide

This document provides installation instructions for Kony Server and other supporting software packages.

(8)

1.3 Deployment Configuration Models

You can use one of the following Deployment Configuration models based on your requirement. The basic difference between the models is that the JMS is configured only on one managed server in Deployment Configuration 1 and all the managed servers on a particular physical box posts messages to the JMS configured on one managed server. This box have only one Kony Reporting Agent.

Note:If SSL is decrypted at Load Balancer, then WebLogic SSL configurations are not required.

Note:If Kony reporting is not required then JMS, Kony Reporting Agents and Log Database are not required to be configured. You can go with file logging instead.

1.3.1 Deployment Configuration 1

(9)

l Decreased load on Middleware server, so relatively significant increase in response times even on heavy load.

l Failure of JMS server does not affect the cluster.

l Multiple Middleware servers can log into single JMS server.

Disadvantages

l Increased hardware configuration as the JMS server has to be setup on a different Managed server.

l The message production rate may be higher than consumption as multiple Middleware servers write to the JMS, but single LogDaemon has to consume it. Hence it is insisted to tune LogDaemon by increasing heap size and increase the batch size properties in logdaemon-jndi.properties.

(10)

Advantages

l Decreased hardware configuration, utilizing one of the Managed server on which Middleware is hosted to host JMS server also.

l Throughput of LogDaemon is relatively high as the message production rate is less than the above architecture.

Disadvantages

l The memory consumption for every user has doubling effect as the memory is consumed by the user session and JMS messages.

l In heavy load, if JMS message consumption is slow, the Middleware response times may get affected.

1.4 SSL Decryption at Load Balancer

For HTTPS decryption to HTTP at Load Balancer (for example, Proxied SSL from Load Balancer to WebLogic Managed Servers), the following headers need to be injected in the Load Balancer configuration /script:

WL-Proxy-SSL: true

WL-Proxy-Dummy-Header: true

Order of adding the headers is important at Load Balancer.

For example, if we configure two ports 80 and 81 in the Load Balancer. Port 80 consumes HTTP traffic received from the device and Port 81 consumes decrypted HTTP traffic received from the Load Balancer. In the Load Balancer, once SSL decryption for HTTPS request is completed, decrypted request is forwarded to HTTP (for example to port 81). Above headers need to be added when decrypted HTTP request is routed to WebLogic Managed Server.

Note:Some Load Balancers such as BigIP F5 have the GUI interface to configure the above options.

1.5 Intended Audience

This document is intended for engineers or system administrators who are

responsible for installing and deploying Kony Server. We assume that the reader of this document is familiar with deploying software on Java application

servers/WebLogic application server. The reader of this document must understand how to install the Database software.

(11)

1.6 Typographical Conventions

Following are the typographical conventions used throughout the document:

Convention Explanation

Monospace

n User input text, system prompts and responses n File Path

n Commands n Program Code n File Names

Italic

n Emphasis

n Names of Books and Documents n New Terminology

Bold

n Windows n Menus n Buttons n Icons n Fields n Tabs

URL Active link to a URL

Note: Provides helpful hints or additional information

Important! Highlights actions or information that might cause problems to systems or data

1.7 Reference Documents

l Kony Database Setup Guide (Oracle/MySQL/DB2) l Kony Studio Installation Guide

l Kony Studio User Guide l Kony Widget User Guide l Kony API Reference Guide

1.8 Contact Us

We welcome your feedback on our documentation. Write to us at [email protected].

(12)

For technical questions, suggestions, comments or to report problems on Kony's product line, [email protected].

(13)

2. Prerequisites

Read this information to understand the System requirements and necessary Software before installing Server. These software need to be pre-installed on the machine on which you install KonyOne Server.

2.1 Hardware Requirements (per physical instance)

Component Requirement

Processor Quad-Core 2.2 GHz

memory 16 GB

Internal Storage 146 GB (15K RPM) with 2 Drives (Raid 1)

Network 2 Gigabit Ethernet Ports

IP Configuration Statically assigned IP addressing

Operating System Linux - CentOS 5.4 / Red Hat Enterprise Linux 5.8

2.2 Software System Requirements (per physical instance)

Purpose Server Name

J2EE Web Container WebLogic 10.3.x / 12c

Java Runtime Environment Bundled JDK 1.6.0_11 for WebLogic 10.3.x Bundled JDK 1.7.0_15 for WebLogic 12c Database (Metrics / Device

Database)

*Database is shared across instances.

MySQL 5.1 / 5.5

Oracle 10g, 11g Standard Editions SQL Server 2008 / 2012

2.3 Database System Requirements (per physical instance)

Component Requirement

Processor Dual Core Processor

memory 16 GB

Internal Storage 73 GB (15K RPM) with 4 Drives (Raid 5)

External Storage 200 GB (RAID 5 + HS) SAN Storage with HA Fiber HBA Connection

Network 2 Gigabit Ethernet Ports

(14)

2.4 Server Software

KonyOne Server software can be downloaded from

https://developer.kony.com/KonyReleases. Navigate to appropriate version and download the files from middleware > Middleware-Without-Memcache folder. Use the download credentials provided by Kony to download the files. The following files are required for this installation:

1. Install.zip

2. middleware-bootconfig.tar

3. middleware.ear

4. admin.war

(for Development and QA environments only)

5. ojdbc14.jar (JDBC Driver for Oracle)

6. sqljdbc4.jar

(for SQL Server database)

7. konylogconfig.tar

8. logdaemon-MID-NO-CACHE-GA-<version>.tar

2.5 Installation Note

The domain/server/configuration names mentioned in this document are used for the convenience of this document, you may use any name suitable for your installation needs.

Make sure that each resource type within a domain must have a name and a JNDI name that is unique for all configuration objects in the domain. Within a domain, each server, machine, cluster, JDBC connection pool, and any other resource type must be named uniquely and must not use the same name as the domain. Therefore, the name you provide for Managed Server, Cluster, JMS Server, JMS Topic, or any other resource should be unique in that domain. The JNDI name provided for JMS resources and JDBC resources must be unique.

Important! The configurations and examples in this document are provided for a better understanding of the concepts. We encourage you not to copy-paste them for your installation execution as this may not match your settings. For example, user names, passwords, IP addresses, port numbers, directory locations and so on.

(15)

3. Install and Configure Kony Server

This section of the document provides you with the instructions for installing and configuring Kony Server. Please make sure that you have the required hardware and access to the supporting software mentioned in the Prerequisites section.

Server Installation Tasks

You need to perform the following tasks to install Kony Server successfully.

n Database Setup

n Configure Kony Server n Configure WebLogic

(16)

3.1 Database Setup

Before you proceed with the installation of Kony Server, make sure to install the Kony Databases. For further information on Kony Database Setup, follow the database setup guide based on the database software at your end:

l Kony Database Setup Guide - Oracle l Kony Database Setup Guide - MySQL l Kony Database Setup Guide - DB2 l Kony Database Setup Guide - MSSQL

(17)

3.2 Configure Kony Server

Perform the following steps to configure Kony Server.

1. Let us assume the user account to be core and path as

/home/core

2. Extract the

install.zip

file to

/home/core

3. Create the folder structure

middleware/middleware-bootconfig

under

/home/core

4. Navigate to

/home/core/install/middleware/middleware-bootconfig

folder.

5. Extract

middleware-bootconfig.tar

file here.

6. After extraction, the following files should be available under middleware-bootconfig folder:

a. ControllerDef.xml -

Orchestrator definition for components related to Kony Server core.

b. antisamy-1.3.xml -

OWASP antisamy XML is an XSS (Cross-Site Scripting) policy file used to make sure that the content is appropriately filtered.

c. jobs.xml -

If there are any daemon processes that needs to be executed, they are defined here.

d. middleware.properties -

General configurations related to the Kony Server like:

i. Name of the Orchestrator definition. ii. Specify the OWASP antisamy xml for XSS. iii. Providing JNDI properties for device database.

iv. Location information for the Service Definition folder.

v. SSL Configurations for Kony Server to connect to the customer enterprise server.

e. middleware-log4j.properties -

Provides log4j configurations for Kony Server. Here we can enable or disable file or jms logging.

f. appregistry folder -

The service definition file

<ServiceDefinition>.xml

is published to this folder.

(18)

Note:If appregistry folder is not available under middleware-bootconfig folder, create a folder with the name appregistry and copy the

<ServiceDefinition>.xml

file here.

7. Edit

middleware.properties

file and make the following changes:

Orchestrator definition for components is related to Kony Server core. Ensure that the ControllerDef.xml is present along with

middleware.properties in middleware-bootconfig folder:

Controller.deffile=ControllerDef.xml

Specify the OWASP antisamy xml for XSS. XSS policy file is used to make sure that the content is appropriately filtered:

middleware.xssconfigfile=antisamy-1.3.xml

Providing JNDI Name for Kony device database.

konycentral.mode

should not be changed. It should always be server.

konycentral.mode=server

konycentral.datasource=jdbc/KDCDB

This property is needed by the Kony Server. Do not make any changes to it.

konycentral.capabilitylist=j2me,markup,blackberry,info

Location information for the Service Definition folder. Ensure that appregistry folder is present in middleware-bootconfig folder.

appregistry.dir=appregistry

SSL Configurations for Kony Server for connecting to the customer enterprise server. These configurations are required only when Kony Server is connecting using the HTTPS protocol.

Uncomment Sun SSL properties and comment IBM SSL properties.

#IBMJSSE2 Security Provider

#ssl.SocketFactory.provider=com.ibm.jsse2.SSLSocketFactoryImpl #ssl.ServerSocketFactory.provider=com.ibm.jsse2.

#SSLServerSocketFactoryImpl #SUN JSSE Security Provider

ssl.SocketFactory.provider=com.sun.net.ssl.internal.ssl. SSLSocketFactoryImpl

(19)

ssl.ServerSocketFactory.provider=com.sun.net.ssl.internal. ssl.SSLServerSocketFactoryImpl

Give location of SSL trust store and key store by setting the properties

ssl.truststoreandssl.keystorerespectively. For example:

ssl.truststore=<JDK_Installation_Path>/jre/lib/security/cacerts ssl.keystore=<JDK_Installation_Path>/jre/lib/security/cacerts

Provide the truststore and keystore passwords by setting

ssl.trustStorePasswordandssl.keyStorePasswordrespectively. The passwords should be entered in clear text.

ssl.trustStorePassword=<password> ssl.keyStorePassword=<password>

Note: Default password for cacerts in the JDK is changeit.

Provide the truststore and keystore types. By default it isJKS. Also, add ssl.algorithm.

ssl.keyStoreType=jks ssl.trustStoreType=jks ssl.algorithm=TLS

The following property shall determine if the truststore passwords, keystore passwords and the passwords in the service-definition files are to be

interpreted as encrypted or in clear text. Mark it as true or false.

use.encryption=true/false End of SSL Configurations.

Set this property to send the Default User Agent to the backend service. Default is set to False. If set to True, default User Agent is sent to the backend service. For Scraping Services, it should be set to false.

send.default.user.agent=false

Kony Server License Configurations

Server License is provided to you by Kony, along with a public key to decrypt the license file. These files can be placed anywhere on the filesystem on the particular physical server.

#License Parameters

LICENSE FILE LOCATION

pubkey.file.path= <Complete path of the public key > license.file.path= <Complete path of the license file >

(20)

LICENSE ACTIVATION CONFIGURATION

customer.firstname=<First name of the customer>

customer.lastname=<Last name of the customer> customer.email=<Customer Email ID>

MAILING PROVIDER CONFIGURATION

mail.Provider.Impl=< Name of the mailing provider.

DefaultMailingProviderImpl is the current SMTP mailing provider implementation. Provide the fully qualified ClassName.>

Example:

com.konylabs.middleware.common.mail.DefaultMailingProviderImpl

SMTP MAIL CONFIGURATION

mail.smtp.host= <The exchange mail server being used. Currently, SMTP servers are supported.> Example: relay.appriver.com

mail.smtp.auth=true <It sets the flag to activate the authentication for the

user session.>

mail.debug=true <It sets the mail logging in debug mode.>

mail.smtp.port= <The port for the mail server. In most cases, the default

port is 2525.>

mail.smtp.starttls.enable=true <It is required when mail server

protected by a SSL layer.>

MAIL SENDER INFORMATION CONFIGURATION

license.mail.from= < Email ID of the person in whose name warning mails are sent, in case of license expiry. > Example: [email protected].

license.mail.fromDisplayName=<Name to be displayed against the

sender’s email.> Example: KONY

license.mail.fromPwd=<Password of the Email ID given above.> Example:

default123

LICENSE RELATED ALERT PROPERTIES

LICENSE EXPIRY WARNING

license.expiry.warning.mail.recipients= < Email ID/IDs of the

recipients to whom the warning mails are sent, in case of license expiry. All values should be comma separated.> Example: [email protected]

license.expiry.warning.mail.cc= <Email IDs of the individuals or the

distribution lists to be included in the CC. All values should be comma separated.>

(21)

distribution lists to be included in the BCC. All values should be comma separated.>

license.expiry.warning.mail.replyto= <Default mail ID to be displayed

in the To List, when the warning mail receiver replies to the warning mail.> Example:[email protected]

license.expiry.warning.mail.subject= <Subject to be displayed in the Subject field of the warning email.> Example: Server license expiry warning.

license.expiry.warning.mail.content= <Default content of the warning email.> Example: The server license is about to expire. Please get it renewed. Note:The configurations provided for

license.expiry.warning.mail.recipients|cc|bcc|replytoparameters act as a fall back for the following optional parameters:

• license.expired.mail.recipients|cc|bcc|replyto. • session.limit.warning.mail.recipients|cc|bcc|replyto. • session.limit.exceeded.mail.recipients|cc|bcc|replyto.

If you do not configure these optional parameters, the information provided for license.expiry.warning.mail.recipients|cc|bcc|replyto is used to send emails. MESSAGE AFTER THE LICENSE IS EXPIRED

#license.expired.mail.recipients= < Email ID/IDs of the recipients to

whom the warning mails are sent after the license is expired. All values should be comma separated.> Example: [email protected]

#license.expired.mail.cc= <Email IDs of the individuals or the distribution lists to be included in the CC. All values should be comma separated.>

#license.expired.mail.bcc= < Email IDs of the individuals or the

#license.expired.mail.replyto= <Default mail ID to be displayed in the To List, when the “License Expired” mail receiver replies to the mail.>

Example:[email protected]

#license.expired.mail.subject= <Subject to be displayed in the Subject field of the “License Expired” email.> Example: Server license has expired.

(22)

Expired” email.> Example: The server license has already expired. Renew the license to avail uninterrupted service.

SESSION RELATED ALERT PROPERTIES

license.mail.session.alert.threshold= <Threshold, in percentage, when the alert needs to be triggered for used sessions. Should never exceed 95%> Example: 70

SESSION COUNT THRESHOLD WARNING

#session.limit.warning.mail.recipients= < Email ID/IDs of the recipients to whom the warning mails are sent after the session count threshold is reached. All values should be comma separated. > Example: [email protected]

#session.limit.warning.mail.cc= <Email IDs of the individuals or the distribution lists to be included in the CC. All values should be comma separated.>

#session.limit.warning.mail.bcc= <Email IDs of the individuals or the distribution lists to be included in the BCC. All values should be comma separated.>

#session.limit.warning.mail.replyto= <Default mail ID to be displayed

in the To List, when the “Session Count Warning” mail receiver replies to the mail.> Example:[email protected]

#session.limit.warning.mail.subject= <Subject to be displayed in the Subject field of the “Session Count Warning” email.> Example: Session limit threshold has crossed.

#session.limit.warning.mail.content= <Default content of the “Session

Count Warning” email.> Example: Your session usage has already crossed the threshold; please plan to extend the sessions for your license.

MESSAGE AFTER THE SESSION COUNT LIMIT EXCEEDED

#session.limit.exceeded.mail.recipients= < Email ID/IDs of the

recipients to whom the warning mails are sent after the session count limit is exceeded. All values should be comma separated.> Example:

[email protected]

(23)

distribution lists to be included in the CC. All values should be comma separated.>

#session.limit.exceeded.mail.bcc= <Email IDs of the individuals or the

#session.limit.exceeded.mail.replyto= <Default mail ID to be displayed in the To List, when the “Session Count Limit Exceeded” mail receiver replies to the mail.> Example: [email protected]

#session.limit.exceeded.mail.subject= <Subject to be displayed in the Subject field of the “Session Count Limit Exceeded” email.> Example: Already exceed the session maximum count.

#session.limit.exceeded.mail.content= <Default content of the

“Session Count Limit Exceeded” email.>

Example: The server has already used the allowed number of sessions, please purchase sessions for your license.

End of License Configurations.

---Used to mask the values of HTTP parameters received to Kony Server. This property is used when Kony Server is running in debug mode. In non-debug mode any application data is not logged. Provide the HTTP parameter names separated by commas to mask their values in log files.

p.exclude=

To disable logging of error stack trace in log files. If it is set to true, it does not log the error stack trace.

mask.trace=false

This property is to disable sending the error message received from back end servers to the device.

log.description.error=false

If you do not want a parameter name to be logged, mention the parameter name in the comma separated format. Valid for both debug and non-debug modes. Leave this configuration empty if you need SessionID based metrics reporting.

(24)

If any specific parameter from session, response header or request header is needed to be logged, mention the parameter name in a comma separated format against respective configurations. Valid for both debug and non-debug modes.

log.specific.session.attribute=userID log.specific.response.header=jid

log.specific.request.header.parameter=

NDC Delimiter is specific to logging in debug and non debug mode. This

specifies the separator between the log messages. Traditional values used are \n for new line and \t for tab.

ndc.delimiter=\n

Specify if JNDI lookups need to be validated by the middleware. jndi.validation=true

Note:Step number eight is optional.

8. After making the above changes to the

middleware.properties

file, execute the below command to encrypt the SSL Keystore and trust store passwords. The

middleware-system.jar

can be found in

middleware.ear/middleware.war/WEB-INF/lib

. Extract the jar from the archive and execute the below command. Skip this step if SSL

communication between Kony Server and customer enterprise server is not required.

Java -cp <File Path>/middleware-system.jar;log4j-1.2.15.jar com.konylabs.middleware.propertiesencryption.PropertiesEncryptD ecrypt

encrypt <File Path>/middleware.properties.

9. Edit

middlware-log4j.properties

file and make the following changes: log4j.properties:

Set to true when JMS logging is configured. Used for validating if the queue is configured or not. Mark it as false if JMS logging is not used.

jms.logging=true

To enable file logging, append "file" to the configuration and provide the file path.

log4j.category.com.kony=ERROR,file log4j.category.com.konylabs=ERROR,file

(25)

Ensure that metrics logging is set to INFO in production environment: log4j.category.com.konylabs.middleware.connectors.

logservice=INFO,jms log4j.additivity.com.konylabs.middleware.connectors. logservice=TRUE

Specific to Log4j for JMS configurations. This can be ignored if

JMS.logging=falseand ensure that JMS is not set for

l

og4j.logger.com.konyand

l

og4j.logger.com.konylabs.

log4j.appender.jms=org.apache.log4j.net.JMSAppender

Specifying

InitialContextFactoryName

property is optional. log4j.appender.jms.initialContextFactoryName=weblogic.jndi. WLInitialContextFactory

Assign the JMS topic and connection factory, defined in Admin Console. Ensure that the names are as specified in the Local JNDI Name.

log4j.appender.jms.TopicBindingName=jms/KonyLogTopic log4j.appender.jms.TopicConnectionFactoryBindingName=jms/ KonyConnectionFactory

End of JMS Configurations.

You can configure to have one log file per day or a log file based on the file size. Once the file size is reached, a new file is created.

For daily log file uncomment the following two lines:

#log4j.appender.file=org.apache.log4j.DailyRollingFileAppender #log4j.appender.file.datePattern='.'yyyy-MM-dd

This is the configuration for the log file based on the file size. When the file size reaches the limit, it creates a new file. Based on the configurations, up to 5 files are retained (log.1 up to log.5). The following three lines are valid for this configuration.

log4j.appender.file=org.apache.log4j.RollingFileAppender log4j.appender.file.maxFileSize=10240KB

log4j.appender.file.maxBackupIndex=5

This is common for all file logging.

Location of the log file. You can change the location where Kony Server log files can be generated.

log4j.appender.file.File=/home/core/middleware.log

Specific to Log4j.

log4j.appender.file.threshold=debug

log4j.appender.file.layout=org.apache.log4j.PatternLayout log4j.appender.file.layout.ConversionPattern=[%x] %d{dd MMM yyyy/HH:mm:ss} %5p %c{2} - %m%n

(26)

3.3 Configure WebLogic Server

After making the necessary modifications to Kony Server files, configure WebLogic Server. Perform the following tasks using WebLogic Administration Console. You need to log in to the Administration Console to perform these operations.

n Create New Domain n Create Cluster

n Configure Application Server n Configure Device Database n Configure License Datasource n Start the Cluster

n Deploy Kony Server

n Configure JMS Server (Optional)

n Persistent JMS Server Configuration (Optional) n Configure SSL (Optional)

3.3.1 Create New Domain

Perform the following steps to create a new domain.

1. Start theConfiguration wizard. You can start the configuration wizard by executingconfig.shunder

WL_HOME/common/bin

.

2. ChooseCreate a new WebLogic domainoption and clickNext.

3. InSelect Domain Sourcewindow choose the default option and clickNext. 4. Specify the domain name as

KonyMiddleware

, and clickNext.

5. Configure the Administrator Username as

weblogic

and Password as

weblogic1

. ClickNext.

6. Configure the Server startup mode asdevelopmentorproduction. 7. Under JDK Selection pane, Select theJDKand clickNext.

8. By default Administration Server is created on port 7001. If you want to modify the port number, then tperform these steps. If you do not want to make any changes, skip to step 9.

l CheckAdministration Serverin the option and ClickNext

(27)

9. ClickNext.

10. ClickCreate.

3.3.2 Create Cluster

A WebLogic Server cluster consists of multiple WebLogic server instances running simultaneously and working together to provide increased scalability and reliability. A Cluster configuration is setup on one of the physical servers on which you want to configure the cluster. The Administration Server runs on this machine only as shown below:

Note:Each server instance in a cluster must run the same version of WebLogic Server.

3.3.2.1 Step 1: Create a Cluster

Perform the following steps to create a Cluster.

1. In the left pane of the Administration Console, expandEnvironmentand select

Clusters. 2. ClickNew.

3. On theCreate a New Cluster > Cluster Propertiespage:

i. Name:Enter the name of the cluster as

MiddlewareCluster

. ii. Messaging Mode:Select Unicast (default).

(28)

3.3.2.2 Step 2: Create Managed Servers

On the physical server on which you want to setup the Administration Server and the Cluster, start the Administration Server and open the Administration Console. On this server create the planned number of Managed Servers. For instance, for a Cluster architecture cited in the above figure, we need nine Managed Servers. So, you need to create nine Managed Servers as described below.

Perform the following steps to create a Managed Server in an existing domain.

1. In the left pane of the Administration Console, selectEnvironment > Servers. 2. In theServerstable, clickNew.

3. On theCreate a New Server > Server Propertiespage: i. Name:Enter the name of the server as

MiddlewareSrv1.

ii. Server Listen Address: Suppose the physical machine has multiple IP addresses, and you wish to restrict the machine to listen to any particular IP address, then provide the particular IP address or DNS name here. If you do not enter any value, WebLogic by default configures the server to listen on all the addresses. Considering the example in the figure above, you can wish to create total nine Managed Servers - three Managed Servers listening to the address of Machine 1, three listening on the address of Machine 2 and three listening on the address of Machine 3. All Managed Servers are created on the physical machine on which Cluster is configured.

iii. Server Listen Port:Enter the port number which is not in use, for instance 8001, from which you want to access the server instance. iv. UnderShould this server belong to a cluster?

l SelectYes, make this server a member of an existing

cluster.

l Select a cluster:Choose the cluster created earlier. v. ClickNext.

vi. ClickFinish.

4. Repeat steps 1 to 3 to create multiple Managed Servers, with a unique name, on this domain.

(29)

3.3.2.3 Step 3: Start the Node Manager

Node Manager is a stand-alone Java program provided with each WebLogic Server installation. You use it to start, stop, and suspend server instances, and to

automatically restart servers that fail. Node Manager must run on each computer that hosts WebLogic Server instances that you want to control with the Node Manager.

You can manually start the node manager by executingstartNodeManagerscript. For WebLogic 11g you can find the script file under

<WL_INSTALL_

DIR>/Middleware/wlserver/server/bin

.

3.3.2.4 Step 4: Create Machines

To start a Managed Server from the cluster for each computer hosting a set of Managed Servers, a Machine has to be configured on the Server where you want to create the cluster.

Perform the following steps to create a Machine.

Machines. 2. ClickNew.

3. On theCreate a New Machine > Machine Propertiespage: l Name: Enter the name of the Machine as

machine1

.

4. Repeat steps 1 to 3 to create multiple Machines, with a unique name, on this domain.

3.3.2.5 Step 5: Configure Machines

Configure the machine to listen to the local or remote Node Manager and add the servers the Machine would control.Perform the following steps to configure Machines.

Machines.

2. Select the Machine created earlier.

3. SelectConfiguration > Node Managertab:

i. Type:Select the Node Manager type from the drop-down list. By default the type of the Node Manager isSSL. It is recommended to go with the default type.

(30)

ii. Listen Address:Enter the DNS name or the IP address on which the Node Manager is listening on this physical server. You can enter

localhost, if the Node Manager is running on the same box.

iii. Listen Port:This is the port where the Node Manager listens for incoming requests. By default, Node Manager listens on port 5556.

iv. ClickSave.

4. SelectConfiguration > Serverstab: i. ClickAdd.

ii. UnderAdd a Server to Machine > Identify Server

l Select a Server:Select the Managed Server created earlier. iii. ClickFinish.

iv. Repeat stepsitoiiito add multiple servers.

5. These steps should be repeated for each system created.

3.3.3 Configure Application Server

Provide JVM parameters using the Administration Console. You need to log in to the WebLogic Administration Console to perform these operations.

Perform the following steps to configure the server. 1. Log in to WebLogic Administration Console.

2. SelectEnvironment > Serversfrom the left menu.

3. Click on theServer on which we need to set the JVM parameters. 4. SelectServer Starttab.

5. In theArguments field, enter the system properties described below:

Parameters (for JVM) Requir

ed Description

-Xmx2048m (Sun) -Xmx:2048m (JRockit)

Yes Minimum Heap size: 2GB -Xms2048m (Sun)

-Xms:2048m (JRockit)

Yes Maximum Heap size: 2GB -XX:UseConcMarkSweepGC (SUN)

-Xgcprio:pausetime (JRockit)

Yes (if Coheren

This setting is recommended when Weblogic is not configured with

(31)

ed Description

ce is not configur ed)

Coherence for Session Caching.

-XX:UseParallelGC (SUN) -Xgcprio:throughput (JRockit) Yes (if Coheren ce is configur ed)

This setting is recommended when Weblogic is configured with Coherence for Session Caching.

-Dmiddleware.home Yes

This is the directory where

middleware/middleware-bootconfig directory is located. For instance, if middleware/middleware-bootconfig is located in /home/core, add–

Dmiddleware.home=/home/core to the arguments.

-Dmiddleware.log4j.dir No

If you want to specify different logging properties for each Managed Server, this property allows you to provide different middleware-log4j.properties for each Managed Server. If the middleware-log4j.properties is placed in

/home/core/server1 for one of the Managed Servers in the cluster, for that Server add–

Dmiddleware.log4j.dir=/home/cor e/server1. Note that this property differs for each Managed Server in the cluster.

-Djava.net.perferIPv4Stack=true Yes

This is a performance tuning setting. Use this setting to avoid the DNS lookup issues between IPv6 and IPv4. As IPv6 stack is preferred by default, if the DNS server is not configured to handle IPv6 queries, the application must wait for the IPv6 query to timeout. This results in slow performance or hang in

HostName lookup. To avoid this and to bypass IPv6, set this to true. Setting this to true makes the Java net process to switch to IPv4.

(32)

ed Description

-Dweblogic.ssl.JSSEEnabled=true|fal se

Yes

Enable or Disable the JSSE-Based SSL Implementation for WebLogic Server from the

weblogic.ssl.JSSEEnabled System Property The following server-side system property enables or disables the JSSE-based SSL implementation by initializing the

SSLMBean.JSSEEnabled attribute: -Dweblogic.ssl.JSSEEnabled=true enables the JSSE-based SSL implementation. This property affects both outbound and inbound SSL connections.

Sample arguments for Managed Server1 would look like:

-Xms2048m –Xmx2048m –Dmiddleware.home=/home/core –

Dmiddleware.log4j.dir=/home/core/server1

Djava.net.perferIPv4Stack=true

-Dweblogic.ssl.JSSEEnabled=true

Note:The following command-line argument can be specified so that WebLogic Server supports only SSL V3.0 or TLS V1.0 connections:

-Dweblogic.security.SSL.protocolVersion=SSL3—Only SSL V3.0 messages are sent and accepted. Attempts by clients to establish connections with a prior SSL version is denied by WebLogic Server, with a denial message returned to the client.

-Dweblogic.security.SSL.protocolVersion=TLS1—Only TLS V1.0 messages are sent and accepted.

-Dweblogic.security.SSL.protocolVersion=ALL—This is the default behavior. Only SSL V3.0 and/or TLS V1.0 messages are sent and accepted.

6. Save the configuration. 7. Restart the server.

8. Perform steps 2 – 7 for all the Managed Servers on which Kony Server has to be deployed.

(33)

3.3.4 Configure Device Database

This step involves the following process:

3.3.4.1 Setup Datasource

Perform the following steps to setup the Datasource.

1. In Administration Console, selectServices > JDBC > Data Sources from the left menu.

2. Click New.

3. Provide the following information:

n Data source name:

konydevicedb

n JNDI Name:

jdbc/KDCDB

4. ClickNextto continue. 5. In the page that appears:

n Select the database driver.

n Enter connection properties like Database Name, Host Name, Port, Database User Name and Password.

6. ClickNextto continue.

7. Select the cluster created earlier, as the target for the data source. 8. ClickFinishto create a datasource for the given details.

3.3.5 Configure License Datasource (Optional)

Note:Skip this step, if you are not using session based license for Kony Server.

This step involves the following process:

3.3.5.1 Setup Datasource

1. In Administration Console, selectServices > JDBC > Data Sources from the left menu.

2. Click New.

3. Provide the following information:

n Data source name:

konyLicenseDS

n JNDI Name:

jdbc/konyLicenseDS

(34)

5. In the page that appears:

n Select the database driver.

n Enter connection properties such as Database Name, Host Name, Port, Database User Name and Password.

7. Select the cluster created earlier, as the target for the data source. 8. ClickFinishto create a datasource for the given details.

3.3.6 Start the Cluster

If you are configuring any of the following settings:

l Configure JMS Server for Managed Server (Optional) l Persistent JMS Server Configuration (Optional) l Configure SSL (Optional)

Start the cluster after you complete the above configurations.

3.3.6.1 Step 1: Create the Managed Server Configuration

The domain configuration currently exists in the machine hosting the Administration Server. We have to copy the domain configuration onto each machine. These copies of the domain configuration are used by the Managed Servers. Run the following commands to create a template of the domain configuration.

Perform the following steps to create a managed server configuration. 1. Navigate to the

common/bin

directory of the WebLogic Home.

cd <WL_HOME>/common/bin

2. Run the pack command to generate the template.

pack.sh -managed=true -domain=<Weblogic_Install_ Dir>/Middleware/user_projects/domain/<domain_name>

-template=<Location_to_store_generated_template>/<template_ name>.jar -template_name=”<template_name>”

A template is created based on which we create domain on the other physical servers.

(35)

3.3.6.2 Step 2: Copy the Managed Server Configuration

Copy the template created in the above step to a temporary location on each

physical machine. Make sure you installed same version of WebLogic Server on each physical machine. Execute the below command to create the domain on each

physical server.

1. Navigate to the

common/bin

directory of the WebLogic Home.

cd <WL_HOME>/common/bin

2. Run the unpack command to create the domain configuration.

unpack.sh -domain=<Weblogic_Install_Dir>/Middleware/user_ projects/domain/<domain_name> -template=<location_of_the_ copied_template>

A domain is created with the provided domain name.

3.3.6.3 Step 3: Enroll the Node Manager

Enroll the Node Manager to make the Managed Servers on the domain to be accessible via the Node Manager. On each machine which is a part of the cluster, perform the following steps:

1. Navigate to

WL_HOME/common/bin.

2. Execute

wlst.sh

. This opens a console to execute the commands required for enrolling the Node Manager.

Initializing WebLogic Scripting Tool (WLST) ...

Welcome to WebLogic Server Administration Scripting Shell Type help() for help on available commands

wls:/offline>

3. Enter

connect('<username>','<password>','t3://<Admin

Host>:<Admin Port>')

, where the username and password are the credentials required to connect to the Administration Server. Below is the sample command:

wls:/offline>connect

('weblogic','weblogic1','t3://KonyServer:8080')

4. Enter

nmEnroll('<Domain Dir>', '<Node Manager Home>')

, where domain directory in our case is

<Weblogic_Install_

Dir>/Middleware/user_projects/domain/<domain_name>

and Node Manager home is usually

WL_HOME/common/nodemanager

.

wls:/KonyMiddleware/serverConfig>nmEnroll('<Weblogic_Install_ Dir>/Middleware/user_projects/domain/<domain_name>', 'WL_ HOME/common/nodemanager')

(36)

Restart the Node Managers on all the machines after performing this step.

3.3.6.4 Step 4: Start the cluster

Perform the following steps to start the cluster.

Clusters.

2. Select the created cluster.

3. On theControlpage, select all the servers and clickStart.

This starts the Managed Servers on all physical servers. The remote start is done through the Node Manager.

This completes the cluster setup. Configure a hardware Load Balancer to complete the load balancing.

3.3.7 Deploy Kony Server

Deploy Kony Server after youstart the Cluster. Download or copy

middleware.ear

and place it on your local machine.

Perform the following steps to deploy Kony Server.

1. In the left pane of the WebLogic Administration Console, selectDeployments. 2. ClickInstall.

3. In theInstall Application Assistant, select the

middleware.ear

by using the folder navigation provided.

4. Let the Target style be the default (Application type deployment) and click

Next.

5. In the Select deployment targets pane, select the cluster created and click

Next.

6. Go toSource accessibilitysection of the Optional Settings pane and choose

Copy this application onto every target for me. 7. ClickFinish.

3.3.8 Configure JMS Server for Managed Server (Optional)

To Configure JMS Server for Managed Server, follow these steps:

n Create JMS Server n Create JMS module

(37)

n Create Connection Factory under JMS module n Create Topic under JMS Module

3.3.8.1 Create JMS Server

Perform the following steps to create the JMS Server. 1. Go To Administration console.

2. SelectServices > Messaging > JMS Serversfrom the left menu. 3. ClickNewin the right pane.

4. Provide the server name as

JMSServer1

.

5. ClickFinish. It takes you to Summary of JMS Serves page. 6. Click on the JMS Server just created.

7. Select theTargetstab.

8. Select a Managed Server from the drop-down list forTarget, on which you want to setup JMS. It may be one among the servers on which Kony Server is

deployed or a dedicated server. 9. Save the configuration.

10. ForDeployment Configuration 2repeat steps 1 to 9 to create JMS Servers, with a unique name (for example,

JMSServer2, JMSServer3

and so on) for other Managed Servers on this domain.

3.3.8.2 Create JMS Module

Perform the following steps to create JMS Module. 1. SelectServices > Messaging > JMS Module.

2. ClickNewin the right pane and provide the module name asSystemModule1.

3. ClickNextand select the Target server from the available list. 4. ClickNextand then clickFinish.

5. Select the System Module that is created. 6. SelectSubdeploymenttab and clickNew. 7. Provide the name as

subdeploy1.

8. ClickNextand select the appropriate JMS Server as the target. 9. ClickFinish.

10. ForDeployment Configuration 2repeat these steps to create JMS Modules, with a unique name (Example.

SystemModule2

,

SystemModule3

and so on) for other Managed Servers on this domain.

(38)

3.3.8.3 Create Connection Factory under JMS Module

Perform the following steps to create Connection Factory under JMS Module.

1. SelectServices > Messaging > JMS Module.

2. In the right pane, you see the SystemModule that was created in the earlier step.

3. Click on

SystemModule1

. 4. ClickNew.

5. Select the optionConnection Factory. 6. Provide the following information:

n Name:

ConnectionFactory1

n JNDI Name:

jms/KonyConnectionFactory1

ClickAdvancedproperties.

n Local JNDI Name:

jms/KonyConnectionFactory

7. ClickNext.

8. Click onAdvanced Targeting.

9. Select

subdeploy1

from the dropdown list forsubdeployment. 10. ClickFinish.

11. For Deployment Configuration 2 repeat these steps to create multiple Connection Factories, with a unique name (For Example:

ConnectionFactory2,

ConnectionFactory3

and so on). and JNDI name (Example.

jms/KonyConnectionFactory2,

jms/KonyConnectionFactory3

and so on). For each Connection Factory, choose appropriate JMS Module (

SystemModule 2, SystemModule3

and so on) and Subdeployment (

subdeploy2 and subdeploy3

and so on). Specify the same Local JNDI Name for every Connection Factory, unless you are specifying a different middleware-log4j.properties using middleware.log4j.dir system property.

3.3.8.4 Create Topic under JMS Module

Perform the following steps to create Topic under JMS Module. 1. SelectServices > Messaging > JMS module.

2. In the right pane, you see the System Module that was created in the earlier step.

(39)

4. ClickNew.

5. Select the optionTopic.

6. Provide the following information: n Name:

Topic1

n JNDI Name:

jms/KonyLogTopic1

ClickAdvancedproperties.

n Local JNDI Name:

jms/KonyLogTopic

7. ClickNext.

8. Click onAdvanced Targeting.

9. Select

subdeploy1

from the dropdown list forsubdeployment. 10. ClickFinish.

11. ForDeployment Configuration 2repeat these steps to create multiple Topics, with a unique name (For example:

Topic2, Topic3

and so on) and JNDI name (for example,.

jms/KonyLogTopic2, jms/KonyLogTopic3

and so on). For each Topic, choose appropriate JMS Module (

SystemModule2,

SystemModule3

and so on) and Subdeployment (

subdeploy2 and

subdeploy3

and so on). Specify the sameLocal JNDI Namefor every Topic, unless you are specifying a different middleware-log4j.properties using

middleware.log4j.dir system property.

3.3.9 Persistent JMS Server Configuration (Optional)

The WebLogic Persistent Store provides a built-in, high-performance storage solution for all subsystems and services that require persistence. For example, it can store persistent JMS messages. Each WebLogic Server instance in a domain has a default persistent store (defined in

config.xml

of the domain) that requires no

configuration and which can be simultaneously used by subsystems that prefer to use the system’s default storage. However, you can also configure a JDBC database-accessible store to suit your JMS implementation.

Important! A file based persistent store can also be configured, but it is not recommended as the performance is degraded.

To Configure Persistent JMS Server, follow these steps:

n Configure a data source to be used by JMS server for persistence n Configuring a Persistent Store

(40)

3.3.9.1 Configure a data source to be used by JMS server for persistence

The DDL scripts for a supported list of databases can be found in the package

weblogic\store\io\jdbc\ddl

in the jar

BEA_

HOME\modules\com.bea.core.store.jdbc_1.0.0.0.jar

. For these

databases the schema is automatically created. If you are using a database whose script is not available in the above location, then create a table named

<prefix>WLStore

with the required schema. An example schema for the Oracle DB

Create Table $prefixWIStore( id int not null primary key, type int not null,

handle int not null, record long raw not null );

Note:You cannot configure a JDBC store to use a JDBC data source that is configured to support global transactions. Instead, it must use a JDBC data source that uses a non-XA JDBC driver.

3.3.9.2 To configure the Data Source

Perform the following steps to configure the Data Source.

1. In the left pane of the Administration Console, selectServices > JDBC > Data Sources.

2. In the right pane, clickNewto create a new Data Source.

3. InJDBC Data SourceProperties, enter the following properties: i. Name:Enter the name of the data source as

JMSStore

. ii. Oracle:Select the database type from the drop-down list.

4. ClickNext.

5. InJDBC Data SourceProperties, select the appropriate database driver. We cannot configure a JDBC store to use a JDBC data source that is configured to support global transactions. Instead, it must use a JDBC data source that uses a non-XA JDBC driver.

6. ClickNext.

(41)

8. ClickNext.

9. InConnectionProperties, enter the following properties: i. Database Name:Enter the database name or SID. ii. Host Name:Enter the host on which database is running.

iii. Port:Enter the port on which we should connect to the database.

iv. Database User Name:Enter the user name required for the connection. v. Password:Enter the password required for the connection.

vi. Confirm Password:Re-enter the above password.

10. ClickNext.

11. InTest Database Connection, verify the auto-populated values are correct. 12. ClickTest Configuration.

13. If theconnection test succeededmessage is seen, proceed further. Else click

Backand correct the details provided. 14. ClickNext.

15. InSelect Targets, select the target on which you have configured JMS server. 16. ClickFinish.

3.3.9.3 Configuring a Persistent Store

Perform the following steps to configure a Persistent Store.

1. In the left pane of the Administration console, selectServices > Persistent Stores.

2. ClickNew > Create JDBC Store. 3. InCreate new JDBC Store:

i. Name:Enter the name of the store, as

JMSStore

.

ii. Target:Select the target server. Select the server on which JMS server is configured.

iii. Data Source:Select the data source created earlier. iv. Prefix:Enterprefixused above for the tableWlStore.

4. Create aJMS storefor the server, if not already done.

5. In the left pane of the Administration console, selectServices >Messaging > JMS Servers.

(42)

i. Select the JMS Server for which persistent store has to be created. ii. Navigate toConfiguration > General.

iii. ForPersistent Store, select the persistent store created earlier. iv. ClickSave.

3.3.10 Configure SSL (Optional)

This is configured for SSL communication between device and the Kony Server.

Note:Skip this section, if SSL traffic is terminated at the Load Balancer.

This step involves the following processes:

l Generate Keystore to save certificates l Configure Keystore

3.3.10.1 Generate Keystore to save certificates

Perform the following steps to generate Keystore to save certificates.

1. Create a Keystore by entering the following command in the operating system shell prompt:

keytool genkey dname "cn=localhost, ou=city, o=city, c=FI" -alias localhost -keypass <password> -keystore <Key Store

Name>.jks -storepass <Password> -validity 3600 Provide <password> and <Key Store Name>

Note:Keystore contains the private key and any certificates necessary to complete a chain of trust and establish the trustworthiness of the primary certificate.

2. Import digitally signed certificate of the client application using the following command:

keytool import file <LOCATION_OF_CERTIFICATE> trustcacerts -alias VRK_ROOT -keystore <KEYSTORE_NAME>

LOCATION_OF_CERTIFICATE: <The physical location of certificate.>

KEYSTORE_NAME: <The key store name which we created in the earlier step.>

3.3.10.2 Configure Keystore

(43)

1. Go to Administration Console.

2. SelectEnvironment > Servers. This page displays the available server instances.

3. Click on the server on which the application server is deployed. 4. In the right pane, select the checkboxSSL Listen Port Enabled. 5. Change the SSL port, if required. ClickSave.

6. Select theKeystoretab and make the following changes:

i. Change Keystore value toCustom Identity and Custom Trust.

ii. Change Custome Identity Keystore value to the location of Java keystore file.

iii. Change Custom Identity Keystore type tojks.

iv. Enter the password. The password is same as the Keystore password. v. Provide the same password for Trust.

vi. ClickSave.

7. Select theSSL tab and make the following changes: i. Change Identity and Trust Locations tokeystores.

ii. Change Private Key Alias to the alias that we gave while creating the keystore.

iii. Change Private Key Passphrase to the password we gave for the keystore. iv. ClickSave.

8. ClickAdvancedlink on the same page. and change Two Way Client Cert BehaviortoClient Certs Requested But Not Enforced.

9. ClickSave.

10. Restart the Server.

3.4 Advanced WebLogic Configurations

This section deals with advanced WebLogic configurations and appropriate changes are required by the Kony Server.

(44)

3.4.1 Network Channel Configuration

A Network Channel is a configurable resource that defines the attributes of a network connection like listening address, listening port, protocol namely, t3, admin, http, https and so on. By default when you create a server, a default channel is created which listens on the address and the port provided while creating the server. By creating the network channels you can segregate different types of network traffic. Here we describe the creation of two network channels to segregate Administration traffic and WebLogic proprietary JMS (t3) traffic from general data traffic (http, https) to managed server.

3.4.1.1 Prerequisites

To suite a general deployment architecture of Kony Server, the document assumes that the user:

l has created a domain.

l has an Administration server running. l has two Managed servers.

l has configured JMS on Managed server (based on deployment configuration). l has created a cluster with the two Managed servers.

l has deployed Kony Server on the cluster.

3.4.1.2 Guidelines when Configuring Channels

Follow the guidelines given below while configuring Channels:

l Each channel you configure for a particular server instance must have a unique combination of Listen Address, Listen Port, and Protocol.

l A channel can be assigned to a single server instance. l You can assign multiple channels to a server instance.

l If you assign non-SSL and SSL channels to the same server instance, make sure that it does not use the same port number.

3.4.1.3 Configure a Network Channel

Start the Administration Console for the domain that contains the server instance you want to configure. Before you configure, stop the Managed server for which the network channel is being configured, else it throws an error.

(45)

1. Navigate toEnvironment > Serversin the left pane of the Administration Console.

2. On the right pane, select the server instance for which you want to configure a channel.

3. Select theProtocols > Channeltab. 4. ClickNewunder Network Channels.

5. InCreate a New Network Channel > Identity properties

l Name:Enter a name for the channel. For example,Admin Channelif we plan to create a channel foradminprotocol.

l Protocol:Choose the protocol for which you wish to create the channel. For example, we chooseadminfor segregating Administration traffic. 6. ClickNext.

7. InCreate a New Network Channel > Network Channel Addressing

l Listen Address:Enter the address to which the channel listens. For example, you wish to specifylocalhostormachine IP addressfor channels like admin as you do not want the Administration requests to come from different machines.

l Listen Port:A unique port on which this channel would listen. Make sure that the port meets the guidelines mentioned above.

8. ClickFinish.

9. Restart the server.

3.4.2 Admin Channel Configuration

While configuring this channel is used by each Managed Server in the domain for communication with the domain's Administration Server. If Administration channel has to be created it has to be created for all the servers in the domain.

To create the channel follow these steps:

1. Configure SSL on each server. Follow the steps provided inConfigure SSL section to configure SSL.

2. Configure a network channel for the Administration Server as defined above in Configure a Network Channelsection and choose the protocol asadminin the step 5 of the configuration.

3. As you complete the configuration for Administration Server by clickingFinish

in the configuration above, your browser is automatically refreshed to load the URL

https://<host>:<admin channel port>/console

.

(46)

From now on, the Administration Console can be accessed on this secure URL only.

4. Restart the Administration Server.

5. In the file system, navigate to the directory where your domain is created. By default it is under

<WL_INSTALL_DIR>/Middleware/user_

projects/domains/<domain name>

6. Open

StartManagedWeblogic.sh

script under

<domain_location>/bin

ADMIN_URL="http://<host>:<port>

and replace the Admin URL with

https://<host>:<admin channel port>

8. Save the

StartManagedWeblogic.sh

script with the above change.

9. Configure a network channel for the other Managed Servers as defined above in Configure a Network Channelsection and choose the protocol asadminin the step 5 of the configuration.

10. Restart all the Managed Servers.

3.4.3 Configure Kony Server for Administration Channel

An Administration channel accepts only secure data. If a server is setup to use Administration channel, then the server does not serve non-SSL requests until the server state is changed to RUNNING. Kony Server tries to validate the JMS properties provided in the

middleware- log4j.properties

in the initial startup. When JMS is configured to use t3 protocol and Administration channel is configured, Kony Server reports fatal errors since non-SSL traffic is restricted during startup. To overcome this issue set the propertyjndi.validationto false in the

middleware.properties

file.

3.4.4 T3 Channel Configuration

You can also configure the servers to segregate the t3 traffic to different ports. During Kony Server setup you may have configured a JMS server on any one Managed Server. The server may actually belong to the cluster on which the Kony Server is deployed. By creating a t3 channel you segregate the JMS traffic and http traffic on that server.

To create a t3 channel follow these steps:

1. Configure a network channel for the server as defined inConfigure a Network Channelsection and choose the protocol ast3in the step 5 of the configuration.

(47)

2. Restart the server.

3. In the

middleware-log4j.properties

file, set the property

log4j.appender.jms.providerURL

to

t3://<host>:<t3 channel

port>

fordeployment configuration 1.

Deploy the Middleware.ear

1. In the left pane of the WebLogic Administration Console, select Deployments. 2. Click Install.

3. In the Install Application Assistant, select the middleware.ear by using the folder navigation provided.

4. In the Select deployment targets pane, select the cluster created and click Next.

5. Go to Source accessibility section of the Optional Settings pane and choose Copy this application onto every target for me.

6. Click Finish.

3.5 Install and Configure Admin Module

Important! Admin module of Kony Server is to be used only in development or testing environment and not in production. We use the Admin module to publish native binaries or services to the Kony Server from Kony IDE.

To install and configure admin module, you need to perform the following steps:

l Add the system property

-Dmiddleware.admin.tmpdir

l Create users in WebLogic

l Deploy admin.war

l Configure deployment-config.properties file l Access Admin Module

3.5.1 Add the system property -Dmiddleware.admin.tmpdir

You need to add the system property

-Dmiddleware.admin.tmpdir,

as a JVM argument to the WebLogic Startup.

(48)

1. Login to Linux console and navigate to

/user_projects/domains/<domain

name>/bin

directory.

2. Open

setDomainEnv.sh

and add the following system property in the section JAVA_PROPERTIES:

-Dmiddleware.admin.tmpdir= <file system path

>

Note:Create a directory with the name "temp" under /home/core directory. This needs to be exported as system variable-Dmiddleware.admin.tmpdir.

Sample arguments would look like:

–Dmiddleware.admin.tmpdir=/home/core/temp

3. Save the configuration and restart the server.

3.5.2 Create users in WebLogic

Create the following WebLogic users and set the passwords:

l admin l publishuser

Perform the following steps to create WebLogic Users.

1. In the WebLogic Administration Console, select services --> Security Realmsfrom the left menu.

2. On the page that appears, click onmyrealm. 3. SelectUsers and Group tab.

4. Under Users, clickNew.

5. Enter the following information:

i. Name- Enter

admin

as the user name.

ii. Password- Enter a password for the admin user.

iii. Confirm Password- Repeat the password entered above for confirmation.

iv. ClickOK.

(49)

Important! Repeat the above steps and create another user by name

publishuser.

Note:Admin application uses the user ID and password created above for authentication.

3.5.3 Deploy admin.war

Perform the following steps to deploy admin.war.

1. In WebLogic Administration Console, selectDeploymentfrom the left menu. 2. In the Summary of Deployments page that appears, clickInstall.

Locate deployment to install and prepare for deploymentpane appears. 3. Selectupload your fileslink, browse and select the

admin.war

file, under

Deployment Archivefield. ClickNext.

We assume that the

admin.war

file is located on the local file system. 4. In the page that appears, clickNext.Install Application Assistantpage

appears.

5. Ensure thatInstall this deployment as an applicationis selected. 6. ClickNext. In the page that appears, clickNext.

7. In the page that appears, clickFinish.

8. In theSettings for adminpage, click Save.

Note:Once this process is complete, click on the Deployments and ensure that the admin application is inActiveState andOKdisplayed against Health.

3.5.4 Configure deployment-config.properties

Configure the

deployment-config.properties

file to point to the above created folders. This file is located at

/home/core/middleware/middleware-bootconfig/admin

folder.

config.names=rc-default

config.rc-default.deploy.dir=<Location of the apps folder> Example:<middleware.home>/apps

app.store.type=FILE

app.store.location=<Location of the appstore folder> Example:<middleware.home>/appstore

Kony Server Installation on Linux Manual WebLogic

Installation on Linux – Manual

– WebLogic

Kony Platform

Release 5

Revision History

Table of Contents

1. Overview

1.1 Kony Server

1.2 Server Installation Guide

1.3 Deployment Configuration Models

1.3.1 Deployment Configuration 1

1.4 SSL Decryption at Load Balancer

1.5 Intended Audience

1.6 Typographical Conventions

1.7 Reference Documents

1.8 Contact Us

2. Prerequisites

2.1 Hardware Requirements (per physical instance)

2.2 Software System Requirements (per physical instance)

2.3 Database System Requirements (per physical instance)

2.4 Server Software

1. Install.zip

2. middleware-bootconfig.tar

3. middleware.ear

4. admin.war

(for Development and QA environments only)

5. ojdbc14.jar (JDBC Driver for Oracle)

6. sqljdbc4.jar

7. konylogconfig.tar

8. logdaemon-MID-NO-CACHE-GA-<version>.tar

2.5 Installation Note

3. Install and Configure Kony Server

3.1 Database Setup

3.2 Configure Kony Server

/home/core

install.zip

/home/core

middleware/middleware-bootconfig

/home/core

/home/core/install/middleware/middleware-bootconfig

middleware-bootconfig.tar

a. ControllerDef.xml -

b. antisamy-1.3.xml -

c. jobs.xml -

d. middleware.properties -

e. middleware-log4j.properties -

f. appregistry folder -

<ServiceDefinition>.xml

<ServiceDefinition>.xml

middleware.properties

konycentral.mode

middleware.properties

middleware-system.jar

middleware.ear/middleware.war/WEB-INF/lib

middlware-log4j.properties

l

l

InitialContextFactoryName

3.3 Configure WebLogic Server

3.3.1 Create New Domain

WL_HOME/common/bin

KonyMiddleware

weblogic

weblogic1

3.3.2 Create Cluster

3.3.2.1 Step 1: Create a Cluster

MiddlewareCluster

3.3.2.2 Step 2: Create Managed Servers

MiddlewareSrv1.

3.3.2.3 Step 3: Start the Node Manager

<WL_INSTALL_

DIR>/Middleware/wlserver/server/bin

3.3.2.4 Step 4: Create Machines

machine1

3.3.2.5 Step 5: Configure Machines

3.3.3 Configure Application Server

-Xms2048m –Xmx2048m –Dmiddleware.home=/home/core –

Dmiddleware.log4j.dir=/home/core/server1

Djava.net.perferIPv4Stack=true