![]() |
iPlanet Trustbase Payment Services 2.0 Beta Systems Administration Guide |
Chapter 3 Running the System
Once you've installed and configured, this chapter shows you how you can test your system is up and running correctly and processing payments requests as expected.
Starting the system
Before checking any particular component you must bring the individual components up and make sure that the system is actually running. Starting the system must be performed in a particular order otherwise components will fail to communicate properly. The order for starting the system is:
Oracle 8.1.7
iMQ for Java 2.0 on both the Buyer and Seller Bank machines
Bank in a Box back end server on the Buyer and Seller Bank machines
Bank in a Box administration tool and iWS 6.0 SP1 on the Buyer and Seller Bank machines
iTPS on the Buyer and Seller machines
iWS 6.0 SP1 on both the Buyer and Seller Bank machines
iAS 6.0 SP3 on both the Buyer and Seller Bank machines
iTTM 3.0.1 on both the Buyer and Seller Bank machines
JMS Proxy on both the Buyer and Seller Bank machines
Buyer web site (BFI) Web server
Tooledup Seller web site Web server The following sections provide instructions for checking that components are running, starting and stopping each component.
Oracle 8.1.7
Oracle 8.1.7 is a complex product and the instructions are intended as a quick list of items that are useful when trying to determine the status of the Oracle installation.
Oracle program files: /opt/oracle/app/product/8.1.7/bin Oracle data files: /identrusdb/orcl Useful information to check on the installation and make a note of:
Useful commands for starting and stopping Oracle. Checking Oracle is running can be performed by looking at the running processes using the process grep or process list commands. If Oracle is not running then you will need to log in as the Oracle superuser and start the Oracle.
nCipher
To check that the nCipher is running perform a process list on each machine. If no nFast process is in the list you will need to start the nFast hard server using the appropriate command.
nfast 4241 1 0 Mar 05 ? 0:22 ../sbin/hardserver -llogfile
nfast 4246 4241 0 Mar 05 ? 0:10 ../sbin/hardserver -llogfile
nCipher KeySafe 1.0
http://www.ncipher.com
iMQ for Java 2.0
iMQ for Java 2.0 needs to be started before iTPS can be run. If you have configured iMQ to start automatically upon reboot but have not yet re-started, use the following:
If it becomes necessary to clear out the contents of the queue then start the broker in the following way
# /opt/SUNWjmq/bin/jmqbroker -reset store
Other commands regarding queue maintenance, can be found on Pages 109-111 of your iMQ for Java Administrator's guide:
http://docs.sun.com/db/prod/s1.ipmsgquj
http://docs.iplanet.com/docs/manuals/javamq/20/admin.pdf
Bank in a Box back End
To run the Bank in a Box back end, run the biab script located in the scripts directory. The script accepts the following arguments, although none are required for normal operation
If the server was started in admin mode, user management may be performed at the BiaB command line. The following commands are accepted:
Bank in a Box Back End can be started as follows:
bash-2.03# ./opt/itps-biab/scripts/biab -debug
[AUDIT] Starting BIAB [V1.0-1001500003703-18]
Bank in a Box administrator tool
The Bank in a Box administrator tool is a Web server application running on iAS 6.0. To check that the Web Server is running use the grep command given below. If the server is not running then start the admin server and use the tools within the adminserver to manage the web server
nobody 9876 1 0 12:52:08 0:00 ./uxwdog -d /opt/iws6/https-myhost.mycompany.com/config
nobody 9877 9876 0 12:52:08 0:01 ns-httpd -d /opt/iws6/https-myhost.mycompany.com/config
iTPS
The iTPS is reliant on three components running:
If all these components have been started correctly then the iTPS component should be available. To check to ensure that the components are running, use the grep commands shown in the tables below. If iTTM is running, but iAS is not, shutdown the iTTM and restart the components starting with iAS 6.0.
iWS 6.0 SP1
nobody 9876 1 0 12:52:08 0:00 ./uxwdog -d /opt/iws6/https-myhost.mycompany.com/config
nobody 9877 9876 0 12:52:08 0:01 ns-httpd -d /opt/iws6/https-myhost.mycompany.com/config
iAS 6.0
Directory Admin: 20000, kas admin:10817, Directory server: 389
To get just the 'kiva' processes (the ones that do the jvm work) do a ps -ef | grep k.s
root 10066 10064 0 14:33:21 0:03 /opt/ias6/ias/bin/.kjs -cset CCS0
root 10059 9504 0 14:33:16 pts/6 0:00 /opt/ias6/ias/bin/.kas
root 9504 1 0 12:47:38 pts/6 0:00 /bin/sh /opt/ias6/ias/bin/kas
root 10070 1 0 14:33:25 0:00 /bin/sh /opt/ias6/ias/bin/kcs -cse t CCS0 -eng 2
root 10064 1 0 14:33:21 ? 0:00 /bin/sh /opt/ias6/ias/bin/kjs -cset CCS0 -eng 1
root 1061 1 0 14:33:19 ? 0:00 /bin/sh /opt/ias6/ias/bin/kxs -cset CCS0 -eng 0
root 10072 10070 0 14:33:25 ? 0:00 /opt/ias6/ias/bin/.kcs -cset CCS0 -eng 2
root 10062 10061 0 14:33:19 ? 0:01 /opt/ias6/ias/bin/.kxs -cset CCS0 -eng 0
nobody 8174 1 0 12:45:04 ? 0:04 ./ns-slapd -f /opt/ias6/slapd-unix
d02/config/slapd.conf -i /opt/ias6/slapd-<Machine-name> (check?)
kxs_0_CCS0: Contains information about the incoming message and the plugin start and stop
kjs_0_CCS0: Contains the standard out from any running java process - can contain some debug information.
http://www.iplanet.com/products/infrastructure/app_servers/index.html
iTTM 3.0.1
Admin via web: 80 (http://myhost.mycompany.com/NASAdapter/logon.html)
root 9658 1 0 12:47:48 pts/6 0:04 /usr/bin/../java/bin/../jre/bin/../bin/sparc/native_threads/java uk.co.jcp.app.
root 9713 1 0 12:47:53 pts/6 0:08 /usr/bin/../java/bin/../jre/bin/../bin/sparc/native_threads/java uk.co.jcp.tbas
root 9790 1 0 12:48:03 pts/6 0:12 /usr/bin/../java/bin/../jre/bin/../bin/sparc/native_threads/java uk.co.jcp.secu
http://docs.sun.com/source/816-6283-10/index.html
http://docs.iplanet.com/docs/manuals/trustbase/3.0.1/icg/contents.htm
If not already running, in a separate window start the iMQ message queue:
/opt/SUNWjmq/bin/jmqbroker -tty
Other commands, such as resetting the queue, can be found on Pages 109-111 of your iMQ for Java Administrator's guide:
http://docs.iplanet.com/docs/manuals/javamq/20/admin.pdf
Buyer and Seller Web applications
These Web applications are both deployed on top of the iWS 6.0 installations on the Buyer and Seller Web site machines. In order to check that these applications are available, use a browser to go to the appropriate URL.
nobody 9876 1 0 12:52:08 0:00 ./uxwdog -d /opt/iws6/https-myhost.mycompany.com/config
nobody 9877 9876 0 12:52:08 0:01 ns-httpd -d /opt/iws6/https-myhost.mycompany.com/config
If the Web Servers are not running then use the process grep (on the host machine) to check that the web server is running. If the Web Server process is not running then start the webserver using the admin console.
Running the Models
We now describe how to run the system for each main kind of Payment Model
Running the Three Corner Model
In this situation the Buyer's Bank is the same as the Seller's Bank, i.e. the buyer and the seller have both been issued with certificates from the same Financial Institution.
User interfaces with the Seller's Website, in this case TooledUp, and initiates a payment
Payment Message gets sent to the iPlanet Trustbase Payment Services Server
iPlanet Trustbase Transaction Manager informs its backend system or in this example Bank in a Box.
Bank in a Box then sends confirmation of payment to TooledUp
The status of this payment initiation is returned back to the seller and hence buyer.
Running the Four Corner Model (SFIM)
Buyer interfaces with Seller's Website, in this particular instance TooledUp, and initiates a payment.
Payment Message gets sent to iPlanet Trustbase Payment Services Server at the Seller's Bank informs its back end systems that in turn informs the Buyers Bank.
Buyers Bank informs back end system, in this case Bank in a Box.
A response is returned to its financial institution
The SFI on receiving the response from the BFI informs its back end systems and response gets sent to the Sellers Website confirming payment.
Making a Payment via the Buyers Bank (BFIM)
If the Subscriber signed data is signed by the Buyer then
Buyer initiates payment from the Buyers Bank Website
Payment Message is sent to iPlanet Trustbase Payment Services that in turn informs the Buyers Bank back end systems.
Response gets returned to Buyers Bank Website
If the seller has signed the subscriber signed data then
Buyer initiates payment from the Buyers Bank Website
Payment Message is sent to iPlanet Trustbase Payment Services that in turn informs the Buyers Bank back end systems.
The BFI informs the seller's SFI
The SFI informs its back end systems
BFI responds back to the buyer
Note More Information about how each payment scheme defines its Models and Payment products can be found at http://www.identrus.com
Example supported Schemes include:
Eleanor Payment Reference Specification
Initiating Payment via Sellers Website TooledUp
You can test the system has been installed correctly by going to the Tooledup Website and initiating a payment as follows.
Go to TooledUp e.g. http://myhost.mycompany.com:80/itps-tdup/logon.html Figure 3-1    TooledUp Main Menu
![]()
Insert Your Smart Card and login. The following menu appears Figure 3-2    TooledUp Ltd Catalogs
![]()
Select a product to purchase Figure 3-3    TooledUp Category Selection
![]()
Add it to the Shopping Basket Figure 3-4    Add to Shopping Basket
![]()
Shopping Basket Details Figure 3-5    Shopping Bag Details
![]()
Make delivery Details Figure 3-6   
![]()
Enter Delivery Details
Make payment. Select Submit at the bottom of the Delivery screen menu
Confirm Delivery Details and Payment type. Choices are
Figure 3-7    Payment Type
![]()
You should the opening chapter in your iTPS Installation Guide for details about what each of these payment types actually mean. Once the user selects <submit>, the following page will be displayed unless a conditional payment product is selected. If a conditional payment product is selected there are screens to allow the user to add conditions before progressing to the next screen. For a worked example of how conditions are actually added see for instance the next chapter "Running the Four Corner Model" and the section "Conditional Payment Order"
Confirm Delivery Details Figure 3-8    Confirm Delivery Details
![]()
Payment Accepted
Figure 3-9    Payment Accepted
![]()
Payment Confirmation
Via your API com.iplanet.trustbase.initiator.cpi
Viewing the Identrus raw_data log (see your iPlanet Trustbase Transaction Manager Developer Guide )
Editing IWS6 startup UNIX script
by adding a debug feature as follows:
./ns-httpd -d $PRODUCT_SUBDIR/config
./$PRODUCT_BIN -d $PRODUCT_SUBDIR/config $@
then run the script as
Check Order List. Finally there is a Tooled Up screen to display confirmed payment requests. Figure 3-10    Order List
![]()
If the user wishes to cancel a payment request then they should select the specific payment they wish to cancel. A cancellation screen should then appear.
Running Bank in a Box Back End
Once the classpath is correct and the queue properties are set, restart the server instance. For instance:
Start the bank in a box back end in a separate window:
Once deployed successfully, the Web Site can be accessed from the browser with the following url. For example,
http://myhost.mycompany.com:80/itps-biab/logon.html
Running Bank in a Box Admin Tool
The Bank in a Box (BiaB) has been expanded to allow it to present a user interface permitting examination of messages received, and sending of response messages. This allows a standard installation of iTPS to be used in a live system, by requiring manual intervention between the BiaB interface and the real bank back end infrastructure. Clearly, this approach is only feasible for very low transaction volumes, but does allow evaluation of the product prior to full scale integration with the existing back end infrastructure. The system also allows you to acknowledge Payments. The following provides a walkthrough of this operation
Make Sure your BiaB Backend Server is running and a username and password has been allocated to. This can be changed by starting the BiaB in Admin mode and typing:
Load the following URL in your browser:
Figure 3-11    Bank in a Box Main Menu
![]()
Enter your username and password, set up by your administrator, as described on the previous page.
Figure 3-12    Bank in a Box Admin Tool Homepage
![]()
There are two selections possible here
Messages in progress. Displays messages that have not been acknowledged with the appropriate response messages yet.
Completed Messages. These are messages that have had the required acknowledgements issued. For Payment Request messages, when the PaymentExecution acknowledgement is sent the message is moved from <Messages in progress> to <Completed Messages>. For PaymentCancellationRequest messages, as soon as a cancellation acknowledgement is sent the cancellation message is moved to the <Completed messages> screen.
Select <messages in progress>
An example screen containing some messages now follows. Clearly the first time there will be no messages. Figure 3-13    BiaB Message Screens
![]()
Figure 3-14    BiaB message searching
![]()
Figure 3-15    BiaB Message Details
![]()
This screen displays details of the original message, plus any acknowledgements that have been sent in conjunction with the message.
Figure 3-16    Acknowledging a message
![]()
Figure 3-17    An XML Message
![]()
Initiating Payment via Buyers Bank Website
This example is of a Web Site hosted by the Buyer's bank accessed by Buyers who belong to the Eleanor Payment Scheme. It provides the ability for the buyer to initiate payment requests and cancellations directly with its bank.
Figure 3-18    Buyers Bank Website Homepage
![]()
Figure 3-19    Initiate Payment
![]()
Details of what each of these fields mean can be found in your payment Scheme Specification
Check the details you have entered are correct and sign the payment using your buyers certificate you configured in the previous chapter Figure 3-20    Sign Payment
![]()
Finally when the payment has been initiated a Payment message will be sent to the URL of the Buyers Bank in which you installed iPlanet Trustbase Payment Services on. The following steps take place:
Figure 3-21    Payment Initiation completed successfully
![]()
Information appears on the Buyers Screen confirming payment. Select <List Payment> to check the information that you have entered has been processed as a payment. Figure 3-22    List Payment
![]()
Condition Management Website
This website will be used by users to alter the status of conditions.
We now illustrate a typical interaction with the Condition Management Website involving a simple purchase by a buyer from the tooledup Website using a Condition payment Order. We introduce two users, each with their own smartcards acting as the following:
A buyer purchasing a product from Tooled Up on Seller's Website
We then assign Users (by issuer and subject on their Smart Cards) Organisations and roles. In this case, we only have one user that needs assignment, the buyer.
telnet buyerbank.buyercompany.com
neworganisation -organisation BFI
newuser -issuer "CN=BuyerBank CA,OU=BuyerBank,O=BuyerBank,C=GB" -subject "CN=Buyer Cert,OU=Buyer,O=Buyer,C=GB" -organisation BFI -email "buyerl@buyercompany.com" -role BUYER
Buyer goes to the TooledUp Web Site hosted by the seller
Figure 3-23    Conditional Payment Order
![]()
Figure 3-24    Approve Payment
![]()
Set Discharge by date to be sometime in the future. This date represents the final day that the CDP will be able to discharge a condition. By "discharge we mean that the CDP has successfully completed the specified condition.
Set the Waive by date to be sometime after the Discharge date. This date represents the last date by which the Buyer can "waive" the requirement that the CDP must discharge the condition. This basically allows the buyer to tell the system to ignore the specified condition.
Note: for the pilot, conditional payments request messages should only contain one discharge-by-date and one waive-by-date. This can be accomplished by either of the following steps:
The user enters only one condition per payment request message in TooledUp
If multiple conditions are included in a payment request, then the discharge-by-dates assigned to each condition must all be the same, and the waive-by-dates assigned to each condition must all be the same
Figure 3-25    A condition has been created
![]()
Figure 3-26    Payment Details
![]()
Figure 3-27    Payment Reference Details
![]()
In order to confirm that the conditional Payment order had reached the bank's back end system, Go to the Biab Admin Screen
The CDP will be sent an email indicating that they have been allocated a condition. A URL of the Condition Management Website is included in this email.
Discharge the Condition as follows. Insert CDP Smart Card and go to the Condition Management Website on the BFI.
Figure 3-28    Payment Reference
![]()
Select the condition relating to your reference number. The status can be change to "CDP Processing", "Discharged" or "Failed".
"CDP processing" indicates that the CDP has accepted this condition.
"Discharged" indicates that the CDP has successfully fulfilled the condition.
"Failed" indicates that the CDP has not accepted or cannot fulfill the condition.
It is possible to attach additional documentation with a condition update message. The limit on this attachment size is 2GB
Select <Associate>
Note the Smartcard Web browser plug-in normally has a much lower restriction on data size than the 2GB the condition Website provides
Select <Discharged>
Finally, since the condition has now been discharged the Buyers Bank makes the payment by returning to the biab website
Figure 3-29    Make the Payment
![]()
Obligation Management Website
This website is used to transfer Obligation Payment products, from the seller to either the BFI or SFI. This website can either be installed at the SFI or BFI. At the SFI, the two roles that can access the site are seller/SFI bank operator. If at BFI, then the only role is BFI bank operator (BANK)
We now illustrate a typical interaction with the Obligation Management Website involving a simple obligation transfer from the Seller to the Buyers bank after a payment is initiated by a buyer from the tooledup Website using a Payment Obligation. There are two roles that need to be assigned
As before,
Assign Users, Organisations and Roles
telnet Sellerbank.sellercompany.com
neworganisation -organisation SFI
newuser -issuer "CN=BuyerBank CA,OU=BuyerBank,O=BuyerBank,C=GB" -subject "CN=Buyer Cert,OU=Buyer,O=Buyer,C=GB" -organisation SFI -email "sellerl@sellercompany.com" -role SELLER
telnet buyerbank.buyercompany.com
neworganisation -organisation BFI
newuser -issuer "CN=BuyerBank CA,OU=BuyerBank,O=BuyerBank,C=GB" -subject "CN=Buyer Cert,OU=Buyer,O=Buyer,C=GB" -organisation BFI -email "buyerbank1@buyerbank.com" -role BANK
Figure 3-30    Making a Payment Obligation
![]()
Figure 3-31    Biab Active Messages Screen
![]()
Figure 3-32    Send Acknowledgement
![]()
Figure 3-33    Send Obligation Acknowledgement Screen
![]()
Figure 3-34    Transfer Obligation
![]()
Running the CPI Test program
Please refer to the Developer Guide
Previous Contents DocHome Index Next
Copyright © 2001 Sun Microsystems, Inc. Some preexisting portions Copyright © 2001 Netscape Communications Corp. All rights reserved.
Last Updated October 22, 2002