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

2. What’s new?

i. Modeling tool agnostic

ii. Generate from simple POJO

iii. JXP Persistence Editor

3. 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.

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

3. 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).

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

5. 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.

2. 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).

3. Start the server.

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

5. 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.

2. 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!

6. Refresh the WebServices project.
7. Locate the file ws-java2wsdl.xml in the WebServices folder of the ChordiantUtils project.
8. Right click on the file and select Run Ant... then choose the targets SecurityMgrBeanClientAgentRpcEnc and MovieClientAgentRpcEnc. Click Run.
9. 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.

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

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