Kony Server Installation on Linux Manual WebLogic

Transcription

1 Kony Server 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 Copyright 2013 by Kony, Inc. All rights reserved. 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. Copyright 2013 Kony, Inc. All Rights Reserved. Page 2 of 78

3 Revision History Date Document Version 08/31/ Document Release for Kony /26/ Description of Modifications/Release Updated the document with MS SQL, DB2, My SQL, Logdaemon configurations. 06/04/ Updated the document with Mobile Web JS configurations. 08/26/ Updated the document with Configure License Datasource as optional. Copyright 2013 Kony, Inc. All Rights Reserved. Page 3 of 78

4 Table of Contents 1. Overview Kony Server Server Installation Guide Deployment Configuration Models Deployment Configuration Deployment Configuration SSL Decryption at Load Balancer Intended Audience Typographical Conventions Reference Documents Contact Us Prerequisites Hardware Requirements (per physical instance) Software System Requirements (per physical instance) Database System Requirements (per physical instance) Server Software Installation Note Install and Configure Kony Server Database Setup Configure Kony Server Configure WebLogic Server Create New Domain Create Cluster Configure Application Server 30 Copyright 2013 Kony, Inc. All Rights Reserved. Page 4 of 78

5 3.3.4 Configure Device Database Configure License Datasource (Optional) Start the Cluster Deploy Kony Server Configure JMS Server for Managed Server (Optional) Persistent JMS Server Configuration (Optional) Configure SSL (Optional) Advanced WebLogic Configurations Network Channel Configuration Admin Channel Configuration Configure Kony Server for Administration Channel T3 Channel Configuration Install and Configure Admin Module Add the system property -Dmiddleware.admin.tmpdir Create users in WebLogic Deploy admin.war Configure deployment-config.properties Access Admin Module Install Reporting Agent Copy reporting agent files Configure the files Upgrade Kony Server Service Definition file - <ServiceDef>.xml Deploy middleware.ear Re-install middleware.ear 55 Copyright 2013 Kony, Inc. All Rights Reserved. Page 5 of 78

6 4.2.2 Verify the upgrade Tuning Linux System Tuning file descriptor limits on Linux Start Services Post Installation Validation Kony Server Error Codes WebLogic Server Logs Appendix - Configuration for Mobile Web JS 78 Copyright 2013 Kony, Inc. All Rights Reserved. Page 6 of 78

7 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: Kony Studio: Designs and develops mobile applications. Kony Server: Provides server side functionality for the applications, common data integration and device support services Client Runtime Component 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 Web channels 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: A sophisticated device database that enables it to detect and deliver the appropriate binary to a requesting device. Inbuilt backend data services integration capability, with out-of-the-box support for Web Services, XML feeds and HTML extraction. Integration with optional third party connector libraries that offer access to a large number of ERP, database and legacy systems. 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. Copyright 2013 Kony, Inc. All Rights Reserved. Page 7 of 78

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 Deployment Configuration 1 Advantages Copyright 2013 Kony, Inc. All Rights Reserved. Page 8 of 78

9 Decreased load on Middleware server, so relatively significant increase in response times even on heavy load. Failure of JMS server does not affect the cluster. Multiple Middleware servers can log into single JMS server. Disadvantages Increased hardware configuration as the JMS server has to be setup on a different Managed server. 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 Deployment Configuration 2 Copyright 2013 Kony, Inc. All Rights Reserved. Page 9 of 78

10 Advantages Decreased hardware configuration, utilizing one of the Managed server on which Middleware is hosted to host JMS server also. Throughput of LogDaemon is relatively high as the message production rate is less than the above architecture. Disadvantages The memory consumption for every user has doubling effect as the memory is consumed by the user session and JMS messages. 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. Copyright 2013 Kony, Inc. All Rights Reserved. Page 10 of 78

11 1.6 Typographical Conventions Following are the typographical conventions used throughout the document: Convention Explanation User input text, system prompts and responses File Path Monospace Commands Program Code File Names Emphasis Italic Names of Books and Documents New Terminology Windows Menus Bold Buttons Icons Fields Tabs URL Note: Important! Active link to a URL Provides helpful hints or additional information Highlights actions or information that might cause problems to systems or data 1.7 Reference Documents Kony Database Setup Guide (Oracle/MySQL/DB2) Kony Studio Installation Guide Kony Studio User Guide Kony Widget User Guide Kony API Reference Guide 1.8 Contact Us We welcome your feedback on our documentation. Write to us at techpubs@kony.com. Copyright 2013 Kony, Inc. All Rights Reserved. Page 11 of 78

12 For technical questions, suggestions, comments or to report problems on Kony's product line, contact Copyright 2013 Kony, Inc. All Rights Reserved. Page 12 of 78

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) Processor memory Component Quad-Core 2.2 GHz 16 GB Requirement Internal Storage 146 GB (15K RPM) with 2 Drives (Raid 1) Network IP Configuration 2 Gigabit Ethernet Ports Statically assigned IP addressing Operating System Linux - CentOS 5.4 / Red Hat Enterprise Linux Software System Requirements (per physical instance) Purpose J2EE Web Container Java Runtime Environment Database (Metrics / Device Database) *Database is shared across instances. WebLogic 10.3.x / 12c Server Name Bundled JDK 1.6.0_11 for WebLogic 10.3.x Bundled JDK 1.7.0_15 for WebLogic 12c MySQL 5.1 / 5.5 Oracle 10g, 11g Standard Editions SQL Server 2008 / Database System Requirements (per physical instance) Processor memory Component Dual Core Processor 16 GB Requirement Internal Storage 73 GB (15K RPM) with 4 Drives (Raid 5) External Storage Network 200 GB (RAID 5 + HS) SAN Storage with HA Fiber HBA Connection 2 Gigabit Ethernet Ports Operating System Linux - CentOS 5.4 / Windows Server 2008 Copyright 2013 Kony, Inc. All Rights Reserved. Page 13 of 78

14 2.4 Server Software KonyOne Server software can be downloaded from 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. Copyright 2013 Kony, Inc. All Rights Reserved. Page 14 of 78

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. Database Setup Configure Kony Server Configure WebLogic Copyright 2013 Kony, Inc. All Rights Reserved. Page 15 of 78

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: Kony Database Setup Guide - Oracle Kony Database Setup Guide - MySQL Kony Database Setup Guide - DB2 Kony Database Setup Guide - MSSQL These documents are available at: Copyright 2013 Kony, Inc. All Rights Reserved. Page 16 of 78

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-bootconfigunder /home/core 4. Navigate to /home/core/install/middleware/middlewarebootconfig folder. 5. Extract middleware-bootconfig.tar file here. 6. After extraction, the following files should be available under middlewarebootconfig 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. Copyright 2013 Kony, Inc. All Rights Reserved. Page 17 of 78

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 Copyright 2013 Kony, Inc. All Rights Reserved. Page 18 of 78

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.truststore and ssl.keystore respectively. 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.truststorepassword and ssl.keystorepassword respectively. 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 is JKS. 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 > Copyright 2013 Kony, Inc. All Rights Reserved. Page 19 of 78

20 LICENSE ACTIVATION CONFIGURATION customer.firstname=<first name of the customer> customer.lastname=<last name of the customer> customer. =<customer 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= < ID of the person in whose name warning mails are sent, in case of license expiry. > Example: sender@konylabs.com. license.mail.fromdisplayname=<name to be displayed against the sender s .> Example: license.mail.frompwd=<password of the ID given above.> Example: default123 LICENSE RELATED ALERT PROPERTIES LICENSE EXPIRY WARNING license.expiry.warning.mail.recipients= < ID/IDs of the recipients to whom the warning mails are sent, in case of license expiry. All values should be comma separated.> Example: warningreceiver@client.com license.expiry.warning.mail.cc= < IDs of the individuals or the distribution lists to be included in the CC. All values should be comma separated.> license.expiry.warning.mail.bcc= < IDs of the individuals or the Copyright 2013 Kony, Inc. All Rights Reserved. Page 20 of 78

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.> license.expiry.warning.mail.subject= <Subject to be displayed in the Subject field of the warning .> Example: Server license expiry warning. license.expiry.warning.mail.content= <Default content of the warning .> Example: The server license is about to expire. Please get it renewed. Note: The configurations provided for license.expiry.warning.mail.recipients cc bcc replyto parameters 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 s. AFTER THE LICENSE IS EXPIRED #license.expired.mail.recipients= < ID/IDs of the recipients to whom the warning mails are sent after the license is expired. All values should be comma separated.> Example: warningreceiver@client.com #license.expired.mail.cc= < IDs of the individuals or the distribution lists to be included in the CC. All values should be comma separated.> #license.expired.mail.bcc= < IDs of the individuals or the distribution lists to be included in the BCC. All values should be comma separated.> #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:info@kony.com #license.expired.mail.subject= <Subject to be displayed in the Subject field of the License Expired .> Example: Server license has expired. #license.expired.mail.content= <Default content of the License Copyright 2013 Kony, Inc. All Rights Reserved. Page 21 of 78

22 Expired .> 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= < 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: #session.limit.warning.mail.cc= < 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= < 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.> #session.limit.warning.mail.subject= <Subject to be displayed in the Subject field of the Session Count Warning .> Example: Session limit threshold has crossed. #session.limit.warning.mail.content= <Default content of the Session Count Warning .> Example: Your session usage has already crossed the threshold; please plan to extend the sessions for your license. AFTER THE SESSION COUNT LIMIT EXCEEDED #session.limit.exceeded.mail.recipients= < 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: #session.limit.exceeded.mail.cc= < IDs of the individuals or the Copyright 2013 Kony, Inc. All Rights Reserved. Page 22 of 78

23 distribution lists to be included in the CC. All values should be comma separated.> #session.limit.exceeded.mail.bcc= < IDs of the individuals or the distribution lists to be included in the BCC. All values should be comma separated.> #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: #session.limit.exceeded.mail.subject= <Subject to be displayed in the Subject field of the Session Count Limit Exceeded .> Example: Already exceed the session maximum count. #session.limit.exceeded.mail.content= <Default content of the Session Count Limit Exceeded .> 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. do.not.log=sessionid Copyright 2013 Kony, Inc. All Rights Reserved. Page 23 of 78

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 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 Copyright 2013 Kony, Inc. All Rights Reserved. Page 24 of 78

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=false and ensure that JMS is not set for log4j.logger.com.kony and log4j.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 Copyright 2013 Kony, Inc. All Rights Reserved. Page 25 of 78

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. Create New Domain Create Cluster Configure Application Server Configure Device Database Configure License Datasource Start the Cluster Deploy Kony Server Configure JMS Server (Optional) Persistent JMS Server Configuration (Optional) Configure SSL (Optional) Create New Domain Perform the following steps to create a new domain. 1. Start the Configuration wizard. You can start the configuration wizard by executing config.sh under WL_HOME/common/bin. 2. Choose Create a new WebLogic domain option and click Next. 3. In Select Domain Source window choose the default option and click Next. 4. Specify the domain name as KonyMiddleware, and click Next. 5. Configure the Administrator Username as weblogic and Password as weblogic1. Click Next. 6. Configure the Server startup mode as development or production. 7. Under JDK Selection pane, Select the JDK and click Next. 8. By default Administration Server is created on port 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. Check Administration Server in the option and Click Next Enter a port (say 7110) which is not in use in the Listen port field. Copyright 2013 Kony, Inc. All Rights Reserved. Page 26 of 78

27 9. Click Next. 10. Click Create 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 Step 1: Create a Cluster Perform the following steps to create a Cluster. 1. In the left pane of the Administration Console, expand Environment and select Clusters. 2. Click New. 3. On the Create a New Cluster > Cluster Properties page: i. Name: Enter the name of the cluster as MiddlewareCluster. ii. Messaging Mode: Select Unicast (default). iii. Click OK. Copyright 2013 Kony, Inc. All Rights Reserved. Page 27 of 78

28 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, select Environment > Servers. 2. In the Servers table, click New. 3. On the Create a New Server > Server Properties page: 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. Under Should this server belong to a cluster? Select Yes, make this server a member of an existing cluster. Select a cluster: Choose the cluster created earlier. v. Click Next. vi. Click Finish. 4. Repeat steps 1 to 3 to create multiple Managed Servers, with a unique name, on this domain. Copyright 2013 Kony, Inc. All Rights Reserved. Page 28 of 78

29 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 executing startnodemanager script. For WebLogic 11g you can find the script file under <WL_INSTALL_ DIR>/Middleware/wlserver/server/bin 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. 1. In the left pane of the Administration Console, expand Environment and select Machines. 2. Click New. 3. On the Create a New Machine > Machine Properties page: 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 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. 1. In the left pane of the Administration Console, expand Environment and select Machines. 2. Select the Machine created earlier. 3. Select Configuration > Node Manager tab: i. Type: Select the Node Manager type from the drop-down list. By default the type of the Node Manager is SSL. It is recommended to go with the default type. Copyright 2013 Kony, Inc. All Rights Reserved. Page 29 of 78

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 iv. Click Save. 4. Select Configuration > Servers tab: i. Click Add. ii. Under Add a Server to Machine > Identify Server Select a Server: Select the Managed Server created earlier. iii. Click Finish. iv. Repeat steps i to iii to add multiple servers. 5. These steps should be repeated for each system created 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. Select Environment > Servers from the left menu. 3. Click on the Server on which we need to set the JVM parameters. 4. Select Server Start tab. 5. In the Arguments field, enter the system properties described below: Parameters (for JVM) -Xmx2048m (Sun) -Xmx:2048m (JRockit) -Xms2048m (Sun) -Xms:2048m (JRockit) -XX:UseConcMarkSweepGC (SUN) -Xgcprio:pausetime (JRockit) Requir ed Yes Yes Yes (if Coheren Description Minimum Heap size: 2GB Maximum Heap size: 2GB This setting is recommended when Weblogic is not configured with Copyright 2013 Kony, Inc. All Rights Reserved. Page 30 of 78

31 Parameters (for JVM) -XX:UseParallelGC (SUN) -Xgcprio:throughput (JRockit) -Dmiddleware.home -Dmiddleware.log4j.dir -Djava.net.perferIPv4Stack=true Requir ed ce is not configur ed) Yes (if Coheren ce is configur ed) Yes No Yes Description Coherence for Session Caching. This setting is recommended when Weblogic is configured with Coherence for Session Caching. 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. 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 middlewarelog4j.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. 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. Copyright 2013 Kony, Inc. All Rights Reserved. Page 31 of 78

32 Parameters (for JVM) Requir ed Description - Dweblogic.ssl.JSSEEnabled=true fal Yes se 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: Sample arguments for Managed Server1 would look like: -Dweblogic.ssl.JSSEEnabled=true enables the JSSE-based SSL implementation. This property affects both outbound and inbound SSL connections. -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. Copyright 2013 Kony, Inc. All Rights Reserved. Page 32 of 78

33 3.3.4 Configure Device Database This step involves the following process: Setup Datasource Perform the following steps to setup the Datasource. 1. In Administration Console, select Services > JDBC > Data Sources from the left menu. 2. Click New. 3. Provide the following information: Data source name: konydevicedb JNDI Name: jdbc/kdcdb 4. Click Next to continue. 5. In the page that appears: Select the database driver. Enter connection properties like Database Name, Host Name, Port, Database User Name and Password. 6. Click Next to continue. 7. Select the cluster created earlier, as the target for the data source. 8. Click Finish to create a datasource for the given details 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: Setup Datasource 1. In Administration Console, select Services > JDBC > Data Sources from the left menu. 2. Click New. 3. Provide the following information: Data source name: konylicenseds JNDI Name: jdbc/konylicenseds 4. Click Next to continue. Copyright 2013 Kony, Inc. All Rights Reserved. Page 33 of 78

34 5. In the page that appears: Select the database driver. Enter connection properties such as Database Name, Host Name, Port, Database User Name and Password. 6. Click Next to continue. 7. Select the cluster created earlier, as the target for the data source. 8. Click Finish to create a datasource for the given details Start the Cluster If you are configuring any of the following settings: Configure JMS Server for Managed Server (Optional) Persistent JMS Server Configuration (Optional) Configure SSL (Optional) Start the cluster after you complete the above configurations 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. Copyright 2013 Kony, Inc. All Rights Reserved. Page 34 of 78

35 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 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') Copyright 2013 Kony, Inc. All Rights Reserved. Page 35 of 78

36 Restart the Node Managers on all the machines after performing this step Step 4: Start the cluster Perform the following steps to start the cluster. 1. In the left pane of the Administration Console, expand Environment and select Clusters. 2. Select the created cluster. 3. On the Control page, select all the servers and click Start. 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 Deploy Kony Server Deploy Kony Server after you start 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, select Deployments. 2. Click Install. 3. In the Install 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 to Source accessibility section of the Optional Settings pane and choose Copy this application onto every target for me. 7. Click Finish Configure JMS Server for Managed Server (Optional) To Configure JMS Server for Managed Server, follow these steps: Create JMS Server Create JMS module Copyright 2013 Kony, Inc. All Rights Reserved. Page 36 of 78

37 Create Connection Factory under JMS module Create Topic under JMS Module Create JMS Server Perform the following steps to create the JMS Server. 1. Go To Administration console. 2. Select Services > Messaging > JMS Servers from the left menu. 3. Click New in the right pane. 4. Provide the server name as JMSServer1. 5. Click Finish. It takes you to Summary of JMS Serves page. 6. Click on the JMS Server just created. 7. Select the Targets tab. 8. Select a Managed Server from the drop-down list for Target, 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. For Deployment Configuration 2 repeat 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 Create JMS Module Perform the following steps to create JMS Module. 1. Select Services > Messaging > JMS Module. 2. Click New in the right pane and provide the module name as SystemModule1. 3. Click Next and select the Target server from the available list. 4. Click Next and then click Finish. 5. Select the System Module that is created. 6. Select Subdeployment tab and click New. 7. Provide the name as subdeploy1. 8. Click Next and select the appropriate JMS Server as the target. 9. Click Finish. 10. For Deployment Configuration 2 repeat these steps to create JMS Modules, with a unique name (Example. SystemModule2, SystemModule3 and so on) for other Managed Servers on this domain. Copyright 2013 Kony, Inc. All Rights Reserved. Page 37 of 78

38 Create Connection Factory under JMS Module Perform the following steps to create Connection Factory under JMS Module. 1. Select Services > Messaging > JMS Module. 2. In the right pane, you see the SystemModule that was created in the earlier step. 3. Click on SystemModule1. 4. Click New. 5. Select the option Connection Factory. 6. Provide the following information: Name: ConnectionFactory1 JNDI Name: jms/konyconnectionfactory1 Click Advanced properties. Local JNDI Name: jms/konyconnectionfactory 7. Click Next. 8. Click on Advanced Targeting. 9. Select subdeploy1 from the dropdown list for subdeployment. 10. Click Finish. 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 ( SystemModule2, 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 Create Topic under JMS Module Perform the following steps to create Topic under JMS Module. 1. Select Services > Messaging > JMS module. 2. In the right pane, you see the System Module that was created in the earlier step. 3. Click on SystemModule1. Copyright 2013 Kony, Inc. All Rights Reserved. Page 38 of 78

39 4. Click New. 5. Select the option Topic. 6. Provide the following information: Name: Topic1 JNDI Name: jms/konylogtopic1 Click Advanced properties. Local JNDI Name: jms/konylogtopic 7. Click Next. 8. Click on Advanced Targeting. 9. Select subdeploy1 from the dropdown list for subdeployment. 10. Click Finish. 11. For Deployment Configuration 2 repeat 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 same Local JNDI Name for every Topic, unless you are specifying a different middleware-log4j.properties using middleware.log4j.dir system property 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 databaseaccessible 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: Configure a data source to be used by JMS server for persistence Configuring a Persistent Store Copyright 2013 Kony, Inc. All Rights Reserved. Page 39 of 78