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 [email protected]. 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: [email protected]. 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: [email protected] 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: [email protected] #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:[email protected] #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

40 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_ 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 To configure the Data Source Perform the following steps to configure the Data Source. 1. In the left pane of the Administration Console, select Services > JDBC > Data Sources. 2. In the right pane, click New to create a new Data Source. 3. In JDBC Data Source Properties, 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. Click Next. 5. In JDBC Data Source Properties, 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. Click Next. 7. In Transaction Options, clear the checkbox Supports Global Transactions. Copyright 2013 Kony, Inc. All Rights Reserved. Page 40 of 78

41 8. Click Next. 9. In Connection Properties, 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. Click Next. 11. In Test Database Connection, verify the auto-populated values are correct. 12. Click Test Configuration. 13. If the connection test succeeded message is seen, proceed further. Else click Back and correct the details provided. 14. Click Next. 15. In Select Targets, select the target on which you have configured JMS server. 16. Click Finish Configuring a Persistent Store Perform the following steps to configure a Persistent Store. 1. In the left pane of the Administration console, select Services > Persistent Stores. 2. Click New > Create JDBC Store. 3. In Create 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: Enter prefix used above for the table WlStore. 4. Create a JMS storefor the server, if not already done. 5. In the left pane of the Administration console, select Services >Messaging > JMS Servers. Copyright 2013 Kony, Inc. All Rights Reserved. Page 41 of 78

42 i. Select the JMS Server for which persistent store has to be created. ii. Navigate to Configuration > General. iii. For Persistent Store, select the persistent store created earlier. iv. Click Save 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: Generate Keystore to save certificates Configure Keystore 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.> Configure Keystore To Configure Kyestore, follow the below steps: Copyright 2013 Kony, Inc. All Rights Reserved. Page 42 of 78

43 1. Go to Administration Console. 2. Select Environment > 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 checkbox SSL Listen Port Enabled. 5. Change the SSL port, if required. Click Save. 6. Select the Keystore tab and make the following changes: i. Change Keystore value to Custom Identity and Custom Trust. ii. Change Custome Identity Keystore value to the location of Java keystore file. iii. Change Custom Identity Keystore type to jks. iv. Enter the password. The password is same as the Keystore password. v. Provide the same password for Trust. vi. Click Save. 7. Select the SSL tab and make the following changes: i. Change Identity and Trust Locations to keystores. 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. Click Save. 8. Click Advanced link on the same page. and change Two Way Client Cert Behavior to Client Certs Requested But Not Enforced. 9. Click Save. 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. Copyright 2013 Kony, Inc. All Rights Reserved. Page 43 of 78

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 Prerequisites To suite a general deployment architecture of Kony Server, the document assumes that the user: has created a domain. has an Administration server running. has two Managed servers. has configured JMS on Managed server (based on deployment configuration). has created a cluster with the two Managed servers. has deployed Kony Server on the cluster Guidelines when Configuring Channels Follow the guidelines given below while configuring Channels: Each channel you configure for a particular server instance must have a unique combination of Listen Address, Listen Port, and Protocol. A channel can be assigned to a single server instance. You can assign multiple channels to a server instance. If you assign non-ssl and SSL channels to the same server instance, make sure that it does not use the same port number 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. Perform the following steps to configure the Network Channel. Copyright 2013 Kony, Inc. All Rights Reserved. Page 44 of 78

45 1. Navigate to Environment > Servers in 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 the Protocols > Channel tab. 4. Click New under Network Channels. 5. In Create a New Network Channel > Identity properties Name: Enter a name for the channel. For example, Admin Channel if we plan to create a channel for admin protocol. Protocol: Choose the protocol for which you wish to create the channel. For example, we choose admin for segregating Administration traffic. 6. Click Next. 7. In Create a New Network Channel > Network Channel Addressing Listen Address: Enter the address to which the channel listens. For example, you wish to specify localhost or machine IP address for channels like admin as you do not want the Administration requests to come from different machines. Listen Port: A unique port on which this channel would listen. Make sure that the port meets the guidelines mentioned above. 8. Click Finish. 9. Restart the server 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 in Configure SSL section to configure SSL. 2. Configure a network channel for the Administration Server as defined above in Configure a Network Channel section and choose the protocol as admin in the step 5 of the configuration. 3. As you complete the configuration for Administration Server by clicking Finish in the configuration above, your browser is automatically refreshed to load the URL channel port>/console. Copyright 2013 Kony, Inc. All Rights Reserved. Page 45 of 78

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 directory 7. Find the pattern ADMIN_URL=" and replace the Admin URL with 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 Channel section and choose the protocol as admin in the step 5 of the configuration. 10. Restart all the Managed Servers 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 property jndi.validation to false in the middleware.properties file 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 in Configure a Network Channel section and choose the protocol as t3 in the step 5 of the configuration. Copyright 2013 Kony, Inc. All Rights Reserved. Page 46 of 78

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> for deployment 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: Add the system property -Dmiddleware.admin.tmpdir Create users in WebLogic Deploy admin.war Configure deployment-config.properties file Access Admin Module 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. Perform the following steps to add the system properties. Copyright 2013 Kony, Inc. All Rights Reserved. Page 47 of 78

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 Create users in WebLogic Create the following WebLogic users and set the passwords: admin publishuser Perform the following steps to create WebLogic Users. 1. In the WebLogic Administration Console, select services --> Security Realms from the left menu. 2. On the page that appears, click on myrealm. 3. Select Users and Group tab. 4. Under Users, click New. 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. Click OK. A message window appears, confirming the creation of the admin user. Copyright 2013 Kony, Inc. All Rights Reserved. Page 48 of 78

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 Deploy admin.war Perform the following steps to deploy admin.war. 1. In WebLogic Administration Console, select Deployment from the left menu. 2. In the Summary of Deployments page that appears, click Install. Locate deployment to install and prepare for deployment pane appears. 3. Select upload your files link, browse and select the admin.war file, under Deployment Archive field. Click Next. We assume that the admin.war file is located on the local file system. 4. In the page that appears, click Next. Install Application Assistant page appears. 5. Ensure that Install this deployment as an application is selected. 6. Click Next. In the page that appears, click Next. 7. In the page that appears, click Finish. 8. In the Settings for admin page, click Save. Note: Once this process is complete, click on the Deployments and ensure that the admin application is in Active State and OK displayed against Health 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/middlewarebootconfig/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 Copyright 2013 Kony, Inc. All Rights Reserved. Page 49 of 78

50 Un comment as displayed below: config.rc-default.type=weblogic config.rc-default.host=<managed server IP address> config.rc-default.port=<managed server HTTP port number> config.rc-default.deploy.dir=/home/core/install/apps Access Admin Module Perform the following steps to access Admin Module. 1. Open a web browser and type Name or IP address>/admin/console. 2. Login to the console by providing the admin username and password for authentication. 3.6 Install Reporting Agent To install the reporting agent, perform the following steps: Copy reporting agent files Configure the files Copy reporting agent files 1. Create a folder with the name konylogdaemon under /home/core. 2. Extract konylogconfig.tar and logdaemon.tar files in /home/core/konylogdaemon folder Configure the files Perform the following steps to configure the files. 1. Navigate to /home/core/install/konylogdaemon folder. 2. Edit the file logdaemon-jndi.properties and make the following changes: The below changes are for reading the log messages from the JMS queue. #-- START - Specific weblogic JMS Server context properties. server=weblogic java.naming.factory.initial=weblogic.jndi.wlinitialcontextfacto ry java.naming.provider.url=t3://<managed Server IP>:7003 Copyright 2013 Kony, Inc. All Rights Reserved. Page 50 of 78

51 logdaemon.topic=jms/konylogtopic logdaemon.connectionfactory=jms/konyconnectionfactory hibernate.config.xml.dir= failover.retries=100 failover.duration=10000 ### Start - Database Test Query for testing DB connection #Oracle and MySql server database query for database.query=select 1 from dual #database query for MS SQL Server #database.query=select 1 #DB2 database query #database.query=select current_timestamp from sysibm.sysdummy1; ### END - Database Test Query for testing DB connection #size of each batch before updating it to DB Server. metrics.update.batchsize=50 csr.update.batchsize=10 logger.update.batchsize=25 download.update.batchsize=50 #LOG Listener ID and Kony log listener ID kony.logging.listener.clientid=konylogginglistener logging.listener=logginglistener #Specify delimiter here Eg.ndc.delimiter=\\t ndc.delimiter=\\n The above configuration is applicable only if development and Quality Analysis servers are in the Deployment Configuration 1, 3. if your are intended to use Deployment Configuration 2, then you can follow the given example where multiple Connection Factories, Topics, each targeted on different JMS Server. Each Connection Factory, Topic, kony.logging.listener.clientid and logging.listener have a different JNDI name. so, They should be pointed appropriately as displayed in the following example: Note:For example if you need to configure the Multiple managed servers, multiple JMS servers, you need to modify the below properties in Logdaemonjndi-properties of logdaemon. First logdaemon logdaemon.topic=jms/konylogtopic logdaemon.connectionfactory=jms/konyconnectionfactory kony.logging.listener.clientid=konylogginglistener logging.listener=logginglistener Second logdaemon Copyright 2013 Kony, Inc. All Rights Reserved. Page 51 of 78

52 logdaemon.topic=jms/konylogtopic1 logdaemon.connectionfactory=jms/konyconnectionfactory1 kony.logging.listener.clientid=konylogginglistener1 logging.listener=logginglistener1 Third logdaemon logdaemon.topic=jms/konylogtopic2 logdaemon.connectionfactory=jms/konyconnectionfactory2 kony.logging.listener.clientid=konylogginglistener2 logging.listener=logginglistener2 To improve the performance of the reporting agent, sql inserts are batched based on the number given below: For metrics info batch: metrics.update.batchsize=50 Valid for Mobile Web - When any exception occurs in jsp page, a message is logged: csr.update.batchsize=10 General logs: logger.update.batchsize=25 Comment the line below: download.update.batchsize=50 Unique IDs specific to the reporting agent. In the Deployment Configuration 2, we configure multiple JMS Servers each targeted on one Managed Server. In this case, we have to run multiple Reporting Agents and ensure that each agent has a unique clientid. kony.logging.listener.clientid=konylogginglistener logging.listener=logginglistener 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. This property should match the delimiter set for ndc.delimiter in middleware.properties file. ndc.delimiter=\n 4. Under JNDI services section, enter the topic and connection factory information. The topic and connection factory is previously created under Configure JMS Server section. 5. Edit the file hibernate.cfg.xml and provide the IP address, database user ID and password in the following lines. This configuration is to ensure that the messages are stored to the database. $ vi hibernate.cfg.xml <!-- These properties are specific to Oracle Database --> Copyright 2013 Kony, Inc. All Rights Reserved. Page 52 of 78

53 <property name="connection.driver_class">oracle.jdbc.driver. OracleDriver</property> <property address>: 1521:<DBName></property> <property name="connection.username">kony LogDB Username</property> <property name="connection.password">kony LogDB Password</property> <property name="dialect">org.hibernate.dialect.oracle10gdialect</propert y> <!-- These properties are specific to MySql Database --> <property name="connection.driver_ class">com.mysql.jdbc.driver</property> <property name="connection.url">jdbc:mysql://<ip address>: 3306:<DBName>?&rewriteBatchedStatements=true</property> <property name="connection.username">kony LogDB Username</property> <property name="connection.password">kony LogDB Password</property> <property name="dialect">org.hibernate.dialect.mysqldialect</property> <!-- These properties are specific to DB2 Database --> <property name="connection.driver_ class">com.ibm.db2.jcc.db2driver </property> <property name="connection.url">jdbc:db2://<ip address/hostname>:50000:dbname</property> <property name="connection.username">kony LogDBUsername</property> <property name="connection.password">kony LogDBPassword</property> <property name="dialect">org.hibernate.dialect.db2dialect</property> <!-- These properties are specific to SQL Server Database --> <property name="connection.driver_ class">com.microsoft.sqlserver.jdbc.sqlserverdriver</property> <property name="connection.url">jdbc:sqlserver:// <DBIPADDRESS:port;databaseName=DBNAME</property> <property name="connection.username">dbusername</property> <property name="connection.password">password</property> <property name="default_schema">konylogdb</property> Copyright 2013 Kony, Inc. All Rights Reserved. Page 53 of 78

54 <property name="dialect">org.hibernate.dialect. SQLServerDialect</property> 6. Edit the file rundaemon.sh. i. Ensure that the JAVA_HOME is set properly as per Sun JDK or JRockit. ii. Set the -Dkonylogdaemon.home property to point to the location of the property files and XMLfiles. In our case, it is - Dkonylogdaemon.home=/home/core/konylogdaemon/bin $ vi /home/core/konylogdaemon/bin/rundaemon.sh Set Java class path for JDK 1.6 Make sure that you provide the fully qualified path for Java correctly. nohup java -server -Xms1G -Xmx1G -XX:MaxPermSize=256M - XX:+HeapDumpOnOutOfMemoryError -Djava.awt.headless=true - Djava.net.preferIPv4Stack=true - Dkonylogdaemon.home=/home/core/konylogdaemon/bin -classpath "$CLASSPATH" com/konylabs/admin/logdaemon/logmsgreciever & Important! Configure java absolute path as per Sun JDK or JRockit Copyright 2013 Kony, Inc. All Rights Reserved. Page 54 of 78

55 4. Upgrade Kony Server In order to upgrade Kony Server, you need perform the following steps: Copy Service Definition file Deploy middleware.ear 4.1 Service Definition file - <ServiceDef>.xml Place <ServiceDef>.xml file in middleware/middlewarebootconfig/appregistry folder and restart middleware application. Note: Restart of middleware application is not required if middleware.ear is redeployed. 4.2 Deploy middleware.ear Follow the steps mentioned in Deploy Kony Server to deploy middleware.ear Re-install middleware.ear Perform the following steps to re-install middleware.ear. 1. Select the application middleware.ear and click Stop. 2. Select the application middleware.ear and click Uninstall. 3. Proceed and perform the steps mentioned in Deploy middleware.ear section Verify the upgrade You can verify if the upgrade is successful by checking the log file. Use one of the following methods to check the log file: In Administration Console, go to Environment > Servers > AdminServer. Select the Logging tab on the right panel. Navigate to the location of the log file (AdminServer.log) on the server. Example file path:../oracle/middleware/user_projects/base_domain_ server/logs/adminserver.log Copyright 2013 Kony, Inc. All Rights Reserved. Page 55 of 78

56 5. Tuning Linux System To run the enterprise applications successfully on Linux distribution, you may have to update some of the default kernel parameter settings. 5.1 Tuning file descriptor limits on Linux In Linux, there is a limit to the number of file descriptors that a process can open. The default is set to 1024 per process. You can increase this limit for optimum performance. Perform the following steps to increase the file descriptor limit. Note: Here we assume weblogic as the user for running the WebLogic server. 1. Login to Linux system and change to weblogic user. 2. Enter the following command: [weblogic@localhost ~]$ ulimit -n If the result is displayed as 32768, skip the following steps. The limit is set for optimum performance. Else, perform the steps to increase the limit. 3. Increase the file descriptors limits. You can limit weblogic user to specific limits by editing /etc/security/limits.conf file. i. Enter the following command to edit the file: vi /etc/security/limits.conf ii. Set weblogic user soft and hard limits by adding the following lines: weblogic soft nofile weblogic hard nofile iii. Save and close the file. Log out and log back in again. iv. Verify the changes by entering the following command: [weblogic@localhost ~]$ ulimit -n It should display Start Services Start the services in the following order: Copyright 2013 Kony, Inc. All Rights Reserved. Page 56 of 78

57 1. Start Managed server Node(s) 2. Start Reporting Agent $ cd /home/core/konylogdaemon/bin $ sh rundaemon.sh Post Installation Validation Perform the following steps to post installation Validation. 1. Check the middleware.log file. It should show successful license validation message. 2. Check the <managed server name>.out file for the successful middleware validation message. If the log displays FATAL ERRORS, verify the setup. 3. Check the successful validation messages in the <managed server name>.out file for the sslkeystore and ssltruststore paths. It should display the path as JAVA_HOME/jre/lib/security/cacerts, as configured in the middleware.properties file. 4. Open the browser and enter or <hostname>:<port>/middleware/version.html. It should display the Build Date, Build Time and the Build Number. 5. Open the browser and enter or <hostname>:<port>/ middleware/mwservlet. It should display "HTTP GET is not supported." Copyright 2013 Kony, Inc. All Rights Reserved. Page 57 of 78

58 6. Kony Server Error Codes The following are the error codes thrown by the Kony Server (middleware). Each error code table consists of the error message, description of the error, severity, way to reproduce the error, error resolution and point of contact. Error 1528 One or more of the services failed in the composite service. This means that one of the services executed as part of the composite service has failed. The actual error code and message can be found in the logs for the individual services. HIGH Provide invalid service URL for one of the services. Resolve the issue faced by the individual service which depends on the error code provided by that service. Depends on the error code for the individual services. Error 5000 Controller Initialization Error. This means that the initialization of the ControllerDef.xml file was improper. LOW Create improper XML tags in the ControllerDef.xml file. Restart the server. While loading the controller configurations, this error is thrown. Please check the ControllerDef.xml file. Error 5001 Mandatory Request parameter channel is missing. Kony Server is being hit from places other than the device. Mandatory parameter channel is missing. SEVERE Remove the request parameter "channel" while invoking the Kony Server. Check the request parameters for mandatory parameter: Copyright 2013 Kony, Inc. All Rights Reserved. Page 58 of 78

59 Error 5001 channel. Error 5002 Mandatory Request parameters - appid, serviceid or both are missing. Kony Server is being hit from places other than the device. All the mandatory parameters such as- appid, serviceid or both are missing. SEVERE Remove the request parameter appid or serviceid while invoking the Kony Server. Check the request parameters for mandatory parameter : appid and serviceid. Error 5004 Processor definition does not exit. This means that the processor classes (DataChunking, ImageProcessor, ServiceDelegate and so on) are not present in the ControllerDef.xml file. This may lead to loss of functionality. Possible tampering. HIGH Remove the <ProcessorConfiguration> with attribute name "ServiceDelegator" from the ControllerDef.xml file. Check controllerdef.xml for the processor being invoked and check if it is present and correct. Error 5005 Cannot load the processor class. This means that the processor classes (DataChunking, ImageProcessor, ServiceDelegate and so on) present in the ControllerDef.xml file could not be loaded by the JVM. This may lead to loss of functionality. Possible tampering. Check availability of the classes. HIGH Modify the <ProcessorConfiguration> tag with attribute name "ServiceDelegator" and change the classname to "abc.xyz". Since this class is not present, it throws up this error. Copyright 2013 Kony, Inc. All Rights Reserved. Page 59 of 78

60 Error 5005 Check if the middleware-system.jar is present and the processor class is present in that jar. Also, check if no other jar file contains the same class name as this processor class. Error 5006 Cannot create processor class instance. This means that the processor classes (DataChunking, ImageProcessor, ServiceDelegate and so on) present in the ControllerDef.xml file could not be instantiated by the JVM. This may lead to loss of functionality. Possible tampering. HIGH Modify the <ProcessorConfiguration> tag with attribute name "ServiceDelegator" and change the classname to "abc.xyz" where abc.xyz is an interface/abstract class. Since this an interface, it throws up this error. Check if the middleware-system.jar is present and the processor class is present in that jar. Also, check if the processor class being invoked is not an interface/abstract class. Error 5101 Sequence definition does not exit. This means that the sequence of processors (as described above) are not present for that particular channel (Native Apps, Mobile Web etc). This should be present in the ControllerDef.xml file. This may lead to loss of functionality. Possible tampering. HIGH Remove the <SequenceConfiguration> with attribute name "default" from the ControllerDef.xml file. Check if the required sequence is present and correctly defined in the controllerdef.xml. Error 5101 Problem in Creating / Loading the sequence class. This means that the sequence of processors (as described Copyright 2013 Kony, Inc. All Rights Reserved. Page 60 of 78

61 Error 5101 above) could not be loaded for that particular channel (Native Apps, Mobile Web and so on). Check ControllerDef.xml file for the sequence. Check availability of the classes defined. This may lead to loss of functionality. Possible tampering. HIGH Modify the <SequenceConfiguration> tag with attribute name "default" and change the classname to "abc.xyz". Since this class is not present, it throws up this error. Check if the sequence class being invoked is present in the middleware-system.jar. Check if no other jar file contains the same class name as this processor class. Also, check if there has been no IllegalAccessError while instantiating the class. Error 5301 No Device ID found for <rcidentifier>. Fallback device not found. Device database may be corrupt or wrong. The Kony Server was unable to locate the fallback device IDs in the device database. SEVERE Remove the entries for 'konyua' and 'konyrc' in the device database. Check the device database if the fallback rcidentifiers konyrc and fallback useragent konyua are present. Also, check the connectivity to the device database. Error 6000 Session does not exist. Session does not exist. MEDIUM Set the session object to null in the pre-processor. Check the pre-processor. Error 6001 Session exists (may be newly created) but there are no expected values. Copyright 2013 Kony, Inc. All Rights Reserved. Page 61 of 78

62 Error 6001 The session exists but the value in the session is null. MEDIUM In the service-definition file, change the scope of an input variable to session and do not save this value in session in the pre-processor or any previous service. Ensure that the value being looked for is present in the session. Check the service-definition file for the particular service and check if the scope of the concerned input variable is correct (It can be session/request). Error 8004 Operation invocation problem. Unable to invoke the method on pre/post processors or the Java services. HIGH Remove the application jar from the application server libraries. Check if the latest application jar is present. Also, check if there is no class conflict in the logs. Error 8005 Response is empty. Backend service is returning empty response. HIGH Re-direct the service call to a dummy server which returns an empty response. Check the back-end services if they are up. Check connectivity with the back-end servers. Back-end service provider. Error 8006 Invalid XML Response. Check response from back-end server. HIGH Create a dummy service on the back-end server to return a HTTP Response with error codes such as 401/500, it throws up this error. Check response string from back-end servers. A common Copyright 2013 Kony, Inc. All Rights Reserved. Page 62 of 78

63 Error 8006 scenario would be when the back-end server returns an HTTP Response (401/500) for an XML/Soap request. This is treated as invalid by Kony Server. Please check if the response from the back-end server is a valid XML or Soap request. Back-end service provider. Error 8007 Error parsing the XML response. This error is returned if the Kony Server could not parse the XML with the given XPath. HIGH Provide incorrect XPath to parse the XML response. Check if the XPath matches the XML response returned by the service. Error 8008 Invalid Result object returned on method invocation. The object returned after invoking the pre/post processor or the Java service does not cast to com.konylabs.middleware.dataobject.result object. HIGH Modify the processor such that it does not return valid Result object. Ensure if proper application jar is present and is returning proper object. Also, check if there is no class conflict in the logs. Error 8009 Request unsuccessful, server responded with status code xxx. If the received status code is not 200, Kony Server throws this error. HIGH Shutdown the service so that a 404 or 500 error is thrown by the server hosting the service. Try to access the service through Kony Server and the error is reproduced. Check if the services are accessible. Back-end service provider. Copyright 2013 Kony, Inc. All Rights Reserved. Page 63 of 78

64 Error 8010 Operation invocation problem. Unable to invoke the method Scraper services. HIGH Remove the scraper.jar from the application server libraries. Check if the latest scraper.jar is present. Also, check if there is no class conflict in the logs. Error 8011 Invalid Result object returned on method invocation. The object returned after invoking the Scraper service does not cast to com.konylabs.middleware.dataobject.result object. HIGH Modify the Scraper code such that it does not return valid Result object. Ensure if proper scraper.jar is present and is returning proper object. Also, check if there is no class conflict in the logs. Error 8013 Cannot get value for the expression. The tag is empty for the particular xpath in the response. LOW Create a service-output parameter which is not present in the response for that particular service. Check the XML response and the service-definition file to ensure that the tag being parsed for is present in the response. Modify the service-definition file if this is not the case. Error 8018 Unable to instantiate object. Unable to invoke the pre/post processors or the Java services. Copyright 2013 Kony, Inc. All Rights Reserved. Page 64 of 78

65 Error 8018 LOW Remove the application jar from the application server libraries. Check if the application jar is present. Also, check if there is no class conflict in the logs. Error 8701 Invalid source to the parameter for<user input text>. Incorrect scope (value of 'src') is used for parameters values. LOW Provide value other than 'request' or 'session'. parameter source must be either of 'request', or 'session'. Error 8702 Request failed with exception:<exception Message>. Exception has occurred while requesting SAP service. HIGH Error 8703 Request failed with JCO exception:<exception Message>. Exception has occurred while requesting SAP service. HIGH Error 8704 Request failed with ABAP exception:<exception Message>. Exception has occurred while requesting SAP service. HIGH Copyright 2013 Kony, Inc. All Rights Reserved. Page 65 of 78

66 Error 8704 Error 8710 Provide the properties file for connection information. SAP properties file (sap_<servername>.properties) config parameter is missing in the service definition. MEDIUM When service does not have properties file in service definition. SAP properties file must be provided in the service definition, using 'sapserverfile' config parameter. Error 8711 Provide 'username' as a request parameter. 'username' is missing from the request parameters. LOW Do not provide username in the service request. Supply the 'username' via request parameter. Error 8712 Provide 'password' as a request parameter. 'password' is missing from the request parameters. LOW Do not provide password in the service request. Supply the 'password' via request parameter. Error 8713 SAP properties not loaded at server load (SAPConnectorListner in web.xml needs to be enabled). SAP properties files are not loaded at server start. LOW Do not register SAPConnectorListener in web.xml. Register SAPConnectorListner in web.xml. Copyright 2013 Kony, Inc. All Rights Reserved. Page 66 of 78

67 Error 8714 Error parsing input parameters. Could not parse the input JSON data supplied. MEDIUM Provide invalid JSON data in the service request. Validate the input data JSON format. Error 8801 Siebel sessionid is empty, login again. Siebel session is empty in the request. LOW Do not provide session ID value. First request the 'login' service which returns the session ID. Pass this session ID in the subsequent service requests. Error 8802 Unsupported Siebel operation - opcode: <opcode value>. Invalid Siebel operation opcode in the request. LOW When opcode does not match valid ones. Siebel service 'opcode' mentioned in the service def is not valid. It has to be either of login, logout, create, update, delete, query, service. Error 8803 Siebel exception while performing operation= <operation> Siebel exception has occurred. HIGH Error 8804 Invalid connection URL or username or password. Invalid URL/username/password for Siebel service. Copyright 2013 Kony, Inc. All Rights Reserved. Page 67 of 78

68 Error 8804 LOW Provide incorrect URL/username/password. Provide correct URL, username, password. Error 8805 Invalid session ID. Session ID is not valid or expired. LOW Provide invalid session ID. Request login service and use the new session ID. Error 8806 Field is multi valued, but mvalue is null. Trying to update/insert multi valued field with single value. LOW Provide single value for multi valued field. Provide multi valued data. Error 8807 Service method not found or more than one found in specified service: <Method Name> in<service Name>. Specified Siebel service is not found. LOW Request a Siebel service which does not exist. Verify the Siebel service name. Error 8901 JMS opcode/propertiesfile/mqconfig cannot be empty. JMS opcode, propertiesfile, mqconfig config parameters are missing from service definition. LOW When opcode/propertiesfile/mqconig config parameters are missing from service definition. Provide correct opcode, properties file, mqconfig config Copyright 2013 Kony, Inc. All Rights Reserved. Page 68 of 78

69 Error 8901 parameters in service definition. Error 8902 Invalid JMS opcode: <JMS opcode value>. Invalid opcode is used. LOW Use opcode other than valid ones. Use correct opcode (either of 'send', 'receive', 'send_ receive'). Error 8903 Properties not loaded at server start: <properties file name>. Invalid opcode used LOW Do not register JmsConnectorListener in web.xml. Register JmsConnectorListener in web.xml. Error 8904 Invalid MQ config name: <MQ Config name> mqconfg name not found in the properties file defined for the service. MEDIUM Do not provide mqconfig config parameter in service definition. Use correct mqconfig. Error 8905 Exception while getting objects from DS. Exception occurred while getting managed JMS objects from directory server. MEDIUM Copyright 2013 Kony, Inc. All Rights Reserved. Page 69 of 78

70 Error 8906 Exception while creating WMQ objects. Exception occurred while creating non-managed JMS connection. MEDIUM Error 8907 JMS connector exception: opcode= <JMS opcode value> Exception occurred while performing JMS operation. HIGH Error 8908 Failed to send message to: <Exception Message>. Failed to send message to mentioned queue/topic. MEDIUM Error 8908 Failed to send message to: <Queue/Topic name>. Failed to send message to mentioned queue/topic. MEDIUM Error 8909 MQ internal error: message sent, but could not get message ID. Message sent, but message ID is not received from MQ server. Copyright 2013 Kony, Inc. All Rights Reserved. Page 70 of 78

71 Error 8909 HIGH Websphere MQ bug Probably a MQ bug Error 8910 JMS StreamMessage type is not handled yet. Not implemented LOW When message is a Stream message. Error 8910 JMS ObjectMessage type is not handled yet. Not implemented LOW When message is Object message. Error 8910 JMS ByteMessage type is not handled yet. Not implemented LOW When message is Byte message. Error 9001 IOExceptions Caused due to read time-outs or due to inability to open a connection. HIGH Create a dummy service on the back-end server to return a response with a MalformedURL exception. This can be done by returning a response with an invalid charset encoding. Check the connectivity to back-end server and check if the Copyright 2013 Kony, Inc. All Rights Reserved. Page 71 of 78

72 Error 9001 response from the back-end server is correct. Back-end service provider. Error 9105 Unable to fill message template. This error is thrown when the Kony Server is unable to create the request XML/Soap message from the input parameters in the request/session. HIGH Pass a dataset as the input variable in the pre-processor for a particular service while keeping the attribute "datatype" of the input variable in the service-definition file as "String". Check the input variables and their datatype. Also, check if the datatype of the input variable is the same as specified in the service-definition file. Error 9109 Unable to open connection to endpoint URL / Unable to open connection for the given service. This error is returned to the device in the event of any exception occurring while connecting and invoking the back-end service through connectors like XML/Soap. Look at the log file for related java stack traces. This error could also appear due to the failure of HTTP client init due to misconfiguration or missing license related values in the middleware.properties file. LOW One of the ways to create this error is to specify an invalid classname "abc.xyz" as the pre-processor for a particular service in the service-definition file and invoke that service. Since this class is not present, this error will be thrown. You could also reproduce this error by removing the SMTP configuration from the middleware.properties file. Check the middleware.log for previous java exceptions and stack-traces. Check the middleware.properties configuration values as mentioned in the Kony Sever installation guide. Copyright 2013 Kony, Inc. All Rights Reserved. Page 72 of 78

73 Error Application does not exist with the AppID. The service definition file has been moved/renamed from it's original location. SEVERE In the service-definition file, change the attribute "id" of the tag <application> to "xyz" and restart the server. Since the application ID is no longer present, this error is thrown. The service definition file has been moved/renamed from it's original location. Check the MIDDLEWARE_ HOME/middleware/ middleware-bootconfig/appregistry/ folder to check if the required service-definition file is present and valid. Re-generate the service. Error Service does not exist with the ServiceID. Kony Server is being hit with an invalid service ID. Possible hack. SEVERE Invoke the middleware application by giving the request parameter serviceid=xyz. Since this serviceid is not present in the service-definition file, this error is thrown. Alternatively, change the service-definition file by changing the attribute name. Check the service-definition file for the particular service being invoked. The <service> tag for that service should be present and should be defined correctly. Error Unsupported service type. Service definition file has been tampered with. Check the type of the service as defined in the service definition. HIGH Change the service-definition file by changing the attribute "type" of a particular service to "abc.xyz". Restart the server. Invoke the service. Since this type is not defined in the ControllerDef.xml file, this error is thrown. Check the service-definition file for the particular service being invoked. Check the attribute "type" in the service tag. This attribute should be present under the Copyright 2013 Kony, Inc. All Rights Reserved. Page 73 of 78

74 Error <ProcessorConfiguration> tag in ControllerDef.xml file along with the appropriate fully qualified class name. Error Cannot load a Connector. Unable to find the class pertaining to the connector specified in the service definition file and ControllerDef.xml file. ClassNotFoundException. Possible tampering of service definition file/libraries. HIGH Change the ControllerDef.xml file by changing the <Config> tag under <ProcessorConfiguration>. Change the attribute "value" for any of the connectors to "abc.xyz". Restart the server. Invoke the service which is of this type. Since the class abc.xyz is not present, this error is invoked. Check the ControllerDef.xml file for fully qualified class name of the particular connector. Also, check if the class is present in the classpath. Error Cannot instantiate a Connector. Unable to instantiate the class pertaining to the connector specified in the service definition file and ControllerDef.xml file. InstantiationException. Possible tampering of service definition file/libraries. HIGH Change the ControllerDef.xml file by changing the <Config> tag under <ProcessorConfiguration>. Change the attribute "value" for any of the connectors to "abc.xyz" where abc.xyz is an interface/abstract class. Restart the server. Invoke the service which uses that particular connector. This error is thrown. Check the ControllerDef.xml file for fully qualified class name of the particular connector. Also, check if the class is present in the classpath and it is not an interface or an abstract class. Copyright 2013 Kony, Inc. All Rights Reserved. Page 74 of 78

75 Error Results fetched is null. The result from the service call is null. Check connection with back-end server and check response from back-end server. Also ensure that the post or pre-processor is not returning empty result. MEDIUM Create a post-processor which returns empty result object. Check connection and response from the back-end server. Check that the pre and post-processor has not returned the empty result. Error Unable to connect to device database. Connection to the device database is lost. Resolve immediately. SEVERE Bring down the database server. Invoke any service and this error is thrown. Check connection to the database server. Check the context specified. Check the credentials of the database server and, if Kony Server has permissions to access the database. Error Unable to close database connection. Unable to close connection to device database. MEDIUM Unable to reproduce the error. Forcefully close the connections to the database server through the application server. Error Error while executing Select Queries. Check the query and manually query the database with the same. Possible tampering with the database tables and/or data. Copyright 2013 Kony, Inc. All Rights Reserved. Page 75 of 78

76 Error HIGH Modify the database and change the name of table "konylogdb.devicemaster" to "konylogdb.devmaster". Since the Kony Server queries the devicemaster table, this error is thrown. Check the query and manually query the database with the same. Possible tampering with the database tables and/or data. Error Unable to load DB Specific Properties. Check the device database properties in the middleware.properties file. Check the existence of the database and manually check if you can connect to the database. SEVERE Remove the file middleware.properties and restart the server. Check the device db properties in the middleware.properties file and check if the middleware.properties file is present in the correct location. Check the existence of the database and manually check, if you can connect to the database. 6.1 WebLogic Server Logs The following table contains the problem scenarios that you may encounter on a WebLogic Server and the resolutions: Scenario Description Resolution DataSource is paused The Connection pool on the datasource can no weblogic.jdbc.extensions.pooldisabledsqlexception: longer offer the weblogic.common.resourcepool.resourcedisabledexception: application server Pool konydevicedb is suspended and cannot allocate any more resources to applications. connections to connect to the database. Release the connections Copyright 2013 Kony, Inc. All Rights Reserved. Page 76 of 78

77 Scenario Description Resolution JMS Server/JMS Topic is paused weblogic.jms.common.illegalstateexception: Destination SystemModule1!KonyLogTopic is paused for new message production. and check the database server. Check the JMS Queue on the server. Restart the JMS Queue. Copyright 2013 Kony, Inc. All Rights Reserved. Page 77 of 78

78 7. Appendix - Configuration for Mobile Web JS Important! This configuration is applicable for WebLogic 10.3.x version only. If you build applications for Mobile Web JS, make the following changes to the WebLogic startup file. 1. Edit startweblogic.sh file to load js.jar first. CLASSPATH="<path>/js.jar:${SAVE_CLASSPATH}" 2. Restart WebLogic server. Copyright 2013 Kony, Inc. All Rights Reserved. Page 78 of 78