Friday, September 4, 2009

Chordiant Space

This blog aims to covers the topics such as Chordiant Decision Management, Chordiant Marketing Director, Chordiant Foundation Server, Chordiant teller and all the other tools and technologies used with Chordiant.
  1. Chordiant Decision Management (CDM)
  2. Chordiant Marketing Director (CMD)
  3. Chordiant Foundation Server (CFS)
  4. Subversion (SVN)
  5. Chordiant Visual Business Director (VBD)
  6. Chordiant Teller

I will be more happy in replying your queries. Please feel free to ask your doubts .

Whats new in CFS 6.3.1

Main >> CFS >> CFS 6.3.1 >> Whats new in CFS 6.3.1



New Features

  1. New Model Driven Development approach
    1. Need for the new approach

i. EOL of RSM 6

    1. What’s new?

i. Modeling tool agnostic

ii. Generate from simple POJO

iii. JXP Persistence Editor

    1. Migration Steps

i. Generate POJO models

ii. Migrate JX Business Components project

a. Convert Meta Information file

b. Migrate generated components

c. Adding POJO models


2. Admin Manager working with Hybrid Registry Connector

a. Hybrid Registry Overview

i. An alternative registry connector that

ii. Chordiant ships with the Foundation Server

iii. Can be configured to load data from a different LDAP system and schema

b. New Feature Overview

i. Admin Manager enhanced to support Hybrid Registry Connector

ii. Code enhancements to integrate CTI with Hybrid Registry

iii. Command/buttons in UI render only when needed



Tech stack change

1. WebSphere 6.1.0 FP 15 is certified

2. CDM/CFS Integration Certified with CDM 6.1.1

a. Apply iFix(PK58537) on WAS v6.1.0.15 with Web Services Feature pack.

3. Certification Change – Corticon Rules

a. Corticon Rules no longer being certified on FS

b. But Corticon rules will still work with CFS 6.3.1

c. With 6.3.5, Corticon jars will not ship with product




CFS 6.3 Index

Main >> CFS >> CFS 6.3.1


  1. Whats new in CFS 6.3.1

CFS 6.0 Index

Main >> CFS >> CFS 6.0


  1. Chordiant support for Web Services

Chordiant support for Web Services

Main >> CFS >> CFS 6.0 >> Chordiant support for Web Services


CHORDIANT SUPPORT FOR WEB SERVICES

Platform independent mechanism for Chordiant and Non-Chordiant systems to work together

  1. Chordiant provides support for RPC-style Web Services only Chordiant Web Services
  2. Chordiant functionality published for use by remote systems
  3. Most Chordiant services are provided as un-deployed Web Services
  4. Non-Chordiant Web Services
  5. Chordiant can use functionality published by other providers

A Web Service is any service available over the Internet that:

  1. Uses a standardized XML messaging system
  2. Is not tied to any Operating System or Programming Language
  3. Is self describing
  4. Is discoverable

Web Services provide a platform independent mechanism for Chordiant and non- Chordiant systems to work together.

With this release, Chordiant functionality may be published as a Web Service for use by non-Chordiant systems. In addition Chordiant may access Web Services published by non-Chordiant providers.

Chordiant supports RPC-style Web Services. This type of Web Services is essentially a Remote Procedure call in which the client sends a SOAP request to execute an operation on the Web Service.

These services are tightly coupled because the sending parameters and return values are as described in WSDL (Web Service Description Language) file and are wrapped in the SOAP body.

NOTE

The alternative Document Style Web Services are loosely coupled and not supported by Chordiant. The request / response are in the form of XML documents. There is no direct mapping between the server objects (parameters, method calls etc.) and the values in XML documents, therefore application has to take care of mapping the XML data values.

Chordiant uses Apache Axis for Web Services support see http://ws.apache.org/axis/index.html for more details.

WEB SERVICE INFRASTRUCTURE

  1. The Web Service infrastructure runs as a servlet
  2. External applications communicate via SOAP over HTTP to contact the web service infrastructure
  3. This in turn contacts the Chordiant Client Agent to invoke the Business Service


The slide shows infrastructure supporting the Web Service. The Web Service infrastructure runs as a servlet within the application server. The Web Services exposed by this servlet are configured using the WSDD created at design time.

External applications using code based on the WSDL file communicate via SOAP over HTTP to contact the web service infrastructure, which in turn contacts the Chordiant Client Agent to invoke the Business Service.

SUPPORTING COMPONENTS

These are the components that support the use of Chordiant Web Services:

  1. WSDL (Web Services Definition Language)
  2. WSDD (Web Services Deployment Descriptor)
  3. Supporting CTP (Eclipse) Projects
    1. ChordiantUtils
    2. WebServices
    3. Custom Proxy project
  4. Ant Scripts
    1. For generation and deployment
  5. Security
    1. SecurityMgrBean Service is published as a Web Service

The components that support the use of Chordiant Web Services include:

  1. WSDL (Web Services Definition Language) - platform independent file containing an XML Grammar to describe the web service. Defines the what, how, where of the web service and includes data types, operations, binding and location information.

  1. WSDD (Web Services Deployment Descriptor) - contain information for deploying the Web Service.

  1. Supporting Eclipse (CTP) Projects - certain Eclipse projects are used in the generation and deployment process including ChordiantUtils (core project), WebServices (deployed web project) and Custom Proxy project (custom project to hold proxy code).

  1. Ant Scripts - uses in the generation and deployment process.

  1. Security - since calling any Chordiant services require a userid and authentication token to be supplied, the SecurityMgrBeanService is published as a Web Service (SecurityMgrBeanClientAgentRpcEnc).

PROVIDED WEB SERVICES

Most Chordiant Business Services can be published as Web Services

  1. The WDSL and WSDD is provide
  2. By default the WSDL is not deployed
  3. See the Application Components Developer’s Guide for a complete list

Most Chordiant services can be published as Web Services. Chordiant provides the WDSL and WSDD. The WSDL for these services are not deployed by default.

CREATING A CHORDIANT WEB SERVICE

The steps involved in creating a Web Service are:

  1. Deploy required CTP projects
  2. WebServices project - Web project to support the infrastructure
  3. Custom Proxy project - Java project to contain the proxy code
  4. Define and generate the WSDL, WSDD and Proxy code for the service
  5. Start the server
  6. Deploy the Web Service
  7. Re-start the server

Creating a Web Service involves the following steps:

  1. Deploy the required CTP projects - this need to be done just once. WebServices is an Eclipse project to which the WSDD is deployed. The Custom Proxy project will hold the infrastructure code for the web service.

  1. Define and generate the WSDL, WSDD and Proxy code - modify and run the appropriate Ant scripts (ws-java2wsdl.xml, ws-wsdl2java.xml or ws-wsdl2java-dynamic.xml).

  1. Start the server.

  1. Deploy the Web Service - modify and run the appropriate Ant script (ws-deploy.xml).

  1. Re-start the server.

CHECKING FOR AVAILABLE WEB SERVICES


To determine which Web Services are available, open a browser and enter the address http://SERVER/WebServices/servlet/AxisServlet where SERVER is the web server.

Lists of deployed web services are displayed. Click the WSDL link to view the WSDL for the service.

ACCESS TO WEB SERVICES

Two mechanisms are provided for distributing the WSDL

  1. Statically
    1. Expose the file through a shared file system
    2. Changes require a manual re-generation of WSDL
  2. Dynamically
    1. Using an established URL, the WSDL is dynamically generated
    2. Up-to-date WSDL is made available
    3. Uses SAAJ (SOAP with Attachments API for Java)

There are two mechanisms provided for distributing WSDL to requestors of published Web Services.

  1. Statically - exposes the WSDL through a shared file system (may be a shared drive or URL). The requestor can build the code to interact with the Web Service, but should the code of the service change, a new WSDL would need to acquire.

  1. Dynamically - exposes the WSDL using an established URL which causes the WSDL to be generated automatically for the requestor if the web service is deployed. The requestor thus receives the most up-to-date copy on request. Note that it is still possible for the requestor’s copy to be out-of-sync if the service code is modified after the WSDL is received.

USING SAAJ TO INVOKE SERVICES

SAAJ can be used as an alternative to writing Java Proxy code. The SOAP with Attachments API for Java (SAAJ) provides a standard way to send XML documents over the Internet from the Java platform. See http://java.sun.com/xml/downloads/saaj.html for more information.

This functionality the WSDL can be invoked by URL and the XML based code is dynamically generated to invoke a Web Service.

DEPLOYING A WEB SERVICE

SCENARIO

The purpose of this lab is deploy one of the Chordiant services as a Web Service. The configuration for the MovieService has been added to the appropriate configuration files.

  • You will deploy it as Web Service MovieClientAgentRpcEnc.
  • You will also deploy the Chordiant provided Web Service SecurityMgrBeanClientAgentRpcEnc.

FILES

List of files used by this exercise:

  1. ws-java2wsdl.xml
  2. ws-wsdl2java.xml
  3. ws-deploy.xml

OBJECTIVES

  1. Generate the WSDL
  2. Generate the Deployment Descriptor
  3. Deploy the Web Service
  4. Verify deployment

INSTRUCTIONS

STEP 1: GENERATE THE WSDL

  1. Start Eclipse.
  2. Refresh the ChordiantUtils project.
  3. In the _CHRD-104_BusinessObjects project, select and execute the make-JARS.xml Ant script using the default target
  4. In the _CHRD-401_BusinessServices project, select and execute the make-JARS.xml Ant script using the default target
  5. Take a look in ChordiantUtils\WebServices\WSDL. You will see several files containing WDSL.

You should see one for SecurityMgrBeanClientAgentRpcEnc but not MovieClientAgentRpcEnc!

  1. Refresh the WebServices project.
  2. Locate the file ws-java2wsdl.xml in the WebServices folder of the ChordiantUtils project.
  3. Right click on the file and select Run Ant... then choose the targets SecurityMgrBeanClientAgentRpcEnc and MovieClientAgentRpcEnc. Click Run.
  4. Refresh the WSDL folder and you should now see a file called MovieClientAgentRpcEnc.wsdl. This is the WSDL for the Movie Web Service.

STEP 2: GENERATE THE DEPLOYMENT DESCRIPTOR

  1. Locate the file ws-wsdl2java2.xml in the WebServices folder of the ChordiantUtils project.
  2. Right click on the file and select Run Ant... then choose the targets SecurityMgrBeanClientAgentRpcEnc and MovieClientAgentRpcEnc. Click Run.
  3. Refresh the WSDD folder and you should see these files containing the Deployment Descriptors
  4. Open the file deploy_SecurityCleantAgentRpcEnc.wsdd in the WSDD folder
  5. Find the element ‘
  6. Change the “*” to “authenticate”. The element should now look like this: ‘
  7. Save your work

STEP 3: DEPLOY THE WEB SERVICE

  1. Start the server.
  2. Locate the file ws-deploy.xml in the WebServices folder of the project.
  3. Right click on the file and select Run Ant... then choose the targets

SecurityMgrBeanClientAgentRpcEnc and MovieClientAgentRpcEnc. Click Run.

  1. Stop the Server.
  2. Open the file server-config.wsdd in the WEB-INF folder of the WebServices project into the text editor.
  3. Delete all occurrences of the string “skeleton” from the file and save the changes.
  4. Restart the Server.
  5. Launch the Browser and enter the URL http://localhost/WebServices/servlet/AxisServlet.
  6. You should see the following in the Browser window:

  1. Click on the wsdl link next to SecurityMgrBeanClientAgentRpcEnc and MovieClientAgentRpcEnc to view the WSDL.

Tuesday, June 2, 2009

CDM Setup : Websphere Standalone profile

Main >> CDM >> CDM Setup : Websphere Standalone profile



Prerequisite

WebShpere Application Server 6.1.0.13
Oracle 10g with CDM schemas on it

Steps

CDM_Installation.book

1. Login to WAS admin console (http://localhost:9060/admin)

2. Create J2C Authentication Entries

2.1. Go to Security >> Secure administration, applications, and infrastructure >> Java Authentication and Authorization Service >> J2C authentication data

2.2. Click on New, and create the following authentication entities

2.2.1. ADS authentication alias

2.2.1.1.Alias Name: ads

2.2.1.2.User Name: ads user name

2.2.1.3.Password: ads user’s password

2.2.2. DMA authentication alias

2.2.2.1.Alias Name: dma

2.2.2.2.User Name: dma user name

2.2.2.3.Password: dma user’s password

2.2.3. DMO authentication alias

2.2.3.1.Alias Name: dmo

2.2.3.2.User Name: dmo user name

2.2.3.3.Password: dmo user’s password

2.2.4. RTDS authentication alias

2.2.4.1.Alias Name: rtds

2.2.4.2.User Name: rtds user name

2.2.4.3.Password: rtds user’s password

2.2.5. IS authentication alias

2.2.5.1.Alias Name: is

2.2.5.2.User Name: is user name

2.2.5.3.Password: is user’s password

2.2.6. RA authentication alias

2.2.6.1.Alias Name: ra

2.2.6.2.User Name: is user name

2.2.6.3.Password: is user’s password

2.3. Click Apply >> Ok.

2.4. Save the changes to master configuration

3. Create JDBC Provider

3.1. Go to Resources >> JDBC >> JDBC Providers >> Select the scope as server1 >> Click on New >> Select the following …

3.1.1. Database type : Oracle

3.1.2. Provider type : Oracle JDBC Driver

3.1.3. Implementation type : Connection pool data source

3.1.4. Name : Oracle JDBC Driver ( you can give any name )

3.1.5. Description : You can give any description

3.2. Click Next

3.3. Specify the path of “ojdbc14.jar” in the text box labeled ${ORACLE_JDBC_DRIVER_PATH} and click >> Next

3.4. Click Finish

3.5. Save the changes to master configuration

4. Create JDBC Data Sources

4.1. Go to Resources >> JDBC >> Data Sources >> Select the scope as server1 >> Click on New

4.2. Create the following data sources

4.2.1. ADS Data source

4.2.1.1.Data source name: adsDataSource

4.2.1.2.JNDI Name: jdbc/adsDataSource

4.2.1.3.Authentication Alias: ads

4.2.2. DMA Data source

4.2.2.1.Data source name: dmaDataSource

4.2.2.2.JNDI Name: jdbc/dmaDataSource

4.2.2.3.Authentication Alias: dma

4.2.3. DMO Data source

4.2.3.1.Data source name: dmoDataSource

4.2.3.2.JNDI Name: jdbc/dmoDataSource

4.2.3.3.Authentication Alias: dmo

4.2.4. RTDS Data source

4.2.4.1.Data source name: rtdsDataSource

4.2.4.2.JNDI Name: jdbc/rtdsDataSource

4.2.4.3.Authentication Alias: rtds

4.2.5. IS Data source

4.2.5.1.Data source name: isDataSource

4.2.5.2.JNDI Name: jdbc/isDataSource

4.2.5.3.Authentication Alias: is

4.2.6. RA Data source

4.2.6.1.Data source name: raDataSource

4.2.6.2.JNDI Name: jdbc/raDataSource

4.2.6.3.Authentication Alias: ra

4.3. Select JDBC provider

4.3.1. Select an existing JDBC provider

4.3.2. And Select Oracle JDBC Driver from the dropdown

4.3.3. Click Next

4.4. Enter the following details

4.4.1. URL: jdbc:oracle:thin:@ Database server IP : DB server port : SID where Database server IP is the IP of database server, port is the port on which Database is running ideally 1521 or 1522 and SID is database name.

4.4.2. Data store helper class name: Oracle10g data store helper

4.5. Click Next

4.6. Click Finish

4.7. Repeat step 4c to 4f.

4.8. Save the changes to master configuration

5. Create & Configure Service Integration Buses

5.1. Go to System Integration >> Buses >> Click on New

5.1.1. Bus name: ADS Bus

5.1.2. Uncheck “Bus Security” option

5.1.3. Click Next

5.1.4. Click Finish

5.2. Go to System Integration >> Buses >> Click on New

5.2.1. Bus name: RTDS Bus

5.2.2. Uncheck “Bus Security” option

5.2.3. Click Next

5.2.4. Click Finish

5.3. Save the changes to master configuration

5.4. Go to System Integration >> Buses >> Select ADS Bus

5.4.1. Click Bus members

5.4.2. Click Add

5.4.3. Click on option button labeled Server and select server1

5.4.4. Click Next

5.4.5. Select the type of message store as “Files store”

5.4.6. Click Next

5.4.7. Keep default settings and click Next

5.4.8. Click Finish

5.5. Go to System Integration >> Buses >> Select RTDS Bus

5.5.1. Click Bus members

5.5.2. Click Add

5.5.3. Click on option button labeled Server and select server1

5.5.4. Click Next

5.5.5. Select the type of message store as “Files store”

5.5.6. Click Next

5.5.7. Keep default settings and click Next

5.5.8. Click Finish

5.6. Save the changes to master configuration

5.7. Go to System Integration >> Buses >> Select ADS Bus

5.7.1. Click Destinations

5.7.2. Click New

5.7.3. Select destination type: Topic Space

5.7.4. Click Next

5.7.5. Identifier: ADS Topic

5.7.6. Click Next

5.7.7. Click Finish

5.7.8. Save the changes to master configuration

5.8. Go to System Integration >> Buses >> Select RTDS Bus

5.8.1. Click Destinations

5.8.2. Click New

5.8.3. Select destination type: Queue

5.8.4. Click Next

5.8.5. Identifier: RTDS

5.8.6. Click Next

5.8.7. Bus member: Select server1

5.8.8. Click Next

5.8.9. Click Finish

5.8.10. Save the changes to master configuration

6. Define the Connection Factories

6.1. Define a Queue Connection Factory

6.1.1. Go to Resources >> JMS >> JMS providers

6.1.2. Select scope as server1 >> Default Messaging Provider

6.1.3. Click on Queue Connection Factories

6.1.4. Click New

6.1.4.1.Name: rtdsQueueConnectionFactory

6.1.4.2.JNDI Name: jms/RTDSQueueConnectionFactory

6.1.4.3.Select bus type: RTDS Bus

6.1.4.4.Click Ok

6.1.4.5.Save the changes to master configuration

6.2. Define a Topic Connection Factory

6.2.1. Go to Resources >> JMS >> JMS providers

6.2.2. Select scope as server1 >> Default Messaging Provider

6.2.3. Click on Topic Connection Factories

6.2.4. Click New

6.2.4.1.Name: adsTopicConnectionFactory

6.2.4.2.JNDI Name: jms/ADSTopicConnectionFactory

6.2.4.3.Bus name: ADS Bus

6.2.4.4.In the provider endpoints: host_name/hostIP:SIB_ENDPOINT_ADDRESS:BootstrapBasicMessaging

6.2.4.5.Click Ok

6.2.4.6.Save the changes to master configuration

7. Define the Queue & topic

7.1. Define Queue

7.1.1. Go to Resources >> JMS >> JMS providers

7.1.2. Select scope as server1 >> Default Messaging Provider

7.1.3. Click on Queues

7.1.4. Click New

7.1.4.1.Name: RTDS Request Queue

7.1.4.2.JNDI Name: queue/DecisionRequestQueue

7.1.4.3.Bus Name: RTDS Bus

7.1.4.4.Queue Name: RTDS

7.1.4.5.Click Ok

7.1.4.6.Save the changes to master configuration

7.1.5. Click New

7.1.5.1.Name: RTDS Reply Queue

7.1.5.2.JNDI Name: queue/DecisionReplyQueue

7.1.5.3.Bus Name: RTDS Bus

7.1.5.4.Queue Name: RTDS

7.1.5.5.Click Ok

7.1.5.6.Save the changes to master configuration

7.2. Define Topic

7.2.1. Go to Resources >> JMS >> JMS providers

7.2.2. Select scope as server1 >> Default Messaging Provider

7.2.3. Click on Topics

7.2.4. Click New

7.2.4.1.Name: ADS Topic

7.2.4.2.JNDI Name: jms/ADSTopic

7.2.4.3.Bus Name: ADS Bus

7.2.4.4.Topic Space: ADS Topic

7.2.4.5.Click Ok

7.2.4.6.Save the changes to master configuration

8. Set Activation specifications

8.1.1. Go to Resources >> JMS >> JMS providers

8.1.2. Select scope as server1 >> Default Messaging Provider

8.1.3. Click on Activation specifications

8.1.4. Click New

8.1.4.1.Name: RTDS Queue

8.1.4.2.JNDI Name: eis/RTDSQueue

8.1.4.3.Destination type: Queue

8.1.4.4.Destination JNDI Name: queue/DecisionRequestQueue

8.1.4.5.Bus Name: RTDS Bus

8.1.4.6.Authentication Alias: node_name/rtds

8.1.4.7.Click Ok

8.1.4.8.Save the changes to master configuration

8.1.5. Click New

8.1.5.1.Name: ADS Topic

8.1.5.2.JNDI Name: eis/ADSTopic

8.1.5.3.Destination type: Topic space

8.1.5.4.Destination JNDI Name: jms/ADSTopic

8.1.5.5.Bus Name: ADS Bus

8.1.5.6.Authentication Alias: node_name/ads

8.1.5.7.Click Ok

8.1.5.8.Save the changes to master configuration