There are several Samples and Demo Tracks to help you walk thru
scenarios for testing data interfaces. Track 1 examples
cover beginner demos, utilizing some default values for config data
that normally would be required as part of new interfaces.
Progressing to more involved Track 2
demos, the intent is to get you running actual Data Interfaces with
as little setup work as possible. After downloading and unzipping the software, and after
moving to the
Track 1A
sample, in only 10 minutes or so, you can see a data interface in operation.
You can send data between systems, review the 2 filesystems involved, and then compare
the actual files on both the source and target systems.
For each of the scenarios listed in the Scenarios List table , in order to walk you thru all aspects of running a demo , the documentation uses a standard format covering inputs, outputs, and verification of the program execution. That format is described here:
| Description | Comment |
|---|---|
| Install Directory |
This is the Root Directory of the software. Before executing the demos,
you need to Change Directory until you are located here.
See
Install Instructions
. |
| Web Service Availability | The client application invoked in all of the demos needs to interact with a web service located at the following URL. The service for the demos is not available 24x7 and for that reason you should run a qwick availibility check before you start running demos. Click here and check that you get a reponse consisting of the WSDL for the service. This will be a page of XML. Additional WSDL background . |
| Shell commands |
ALL EXAMPLES use the same shell, located in the bin
directory.
On Windows
invoke the shell with bin\b2bpo ${parms}. On *NIX systems,
use
bin/b2bpo ${parms}. Some of the Demo Tracks
only list which parameters to use. It is assumed that you will key in the correct
shell command before keying the parameter values.
|
| command line parms | Parameters Documentation is
here
and in
Java Class=FileTopicType.
On the command line, following the shell expression, Parm values need to be supplied.
These occur where you see the ${parms} above.
The distinction amoung the Demo Sample Tracks is usually a single Parameter value that
is entered on the command line following the shell command. For example, moving from
Track 1B to Track 1C involves
the addition of a single parameter
( data.source.lastfile )
. |
| Output | Each time you run a demo, print instructions processed by the software on SYSTEM.OUT
will appear in the shell console or you may PIPE
them to a file. An architecture review
here
serves to remind that the software uses collaboration amoung a number of HOST Machines.
The Demo samples invoke client processes that get WEB connections
and that invoke Web Services over the WEB connection. On the Remote machine where the
PostOffice
WEB service is running, in response to the Request made by running the Demo, a
Dispatcher will queue up work necessary to launch other threads and to
complete any Subscriber connections and Subscriber distribution of the data from the Client.
Included within the output stream on the Client machine are diagnostic
messages originating from 3 areas :
|
| Part 1 |
LOCAL_APP Output
contains a list of Property values picked up in the local machine from the file
config/ftp.properties
|
| Part 2 |
CONNECT_INFRASTRUCTURE Output
Courtesy of a Middleware implementation from
Apache AXIS Project
, JAX-RPC, and SOAP Web-Services are used by this software. Each time
a
Soap message
passes over the Client/ Server connections, there is a copy of the actual
response message from the Server dumped to
System.Out. To better understand the contents, a little background on
SAAJ or
"Soap with Attachments" is available at:
Messages with Attachments.
By scrolling down the selection and by observing the pictures, you get a feel
for SOAP Message Structure and will probably understand what you see next to
the Output for each demo in Part 2.
Part 2 contains the XML for the SOAPEnvelope
as it was encoded and dumped on the wire by the Server-side portion of the application.
|
| Part 3 |
Following the above discussion, the SOAP Envelope and the
Attachment Part are both encapsulated by the Soap Message.
The server-side Java methods called by the Web-Services employed by these demos
are methods that produce chunks of XML that comprise
Channel Data Commands. Channel Data commands are the
objects that are dispatched by the Post Office during the fufillment of its responsibilites
that direct data to each of the Subscribers of a Topic. So, the actual ChannelData Command
used by the server is also copied and returned to the Client as a SOAP Attachment. This is
what appears in Part 3.
|
| Dispatcher | WAIT for 30 seconds and proceed to the next item.
This allows time for the Dispatcher at the Post Office to complete
some Actions related to Subscriptions. Within 20 seconds, the dispatcher should be
done with connections to each subscriber, and with copying data to those subscribers.
|
| Verify Data Transfer | "So where did my data go in these interfaces constructed by the Demo?"
A closer examination of the Part 3 Output and several elements
within the XML will help answer the question. Of particular interest are the elements:
server
and the targetdirectory. Once you are there, look for files in the list
with names matching the regex. Try looking at
Track 1 and
Track 2 following your test runs.
|
| Additional Background |
When the Web-Services request initiated and sent by the demo running on your client machine
arrives at the PostOffice's JAX-RPC layer
there is an associated HTTP Session. For logging purposes, this Session ID is preserved
in the session element for later use as a "transaction ref-ID" and as a way of
logging the receipt by the server of a request to do PUB/SUB work
and the receipt of the actual data files from the Client. Now, another ID, associated to the
first one, is used to log the actual File copy operation.
For a short interval between receipt from the Publisher and re-transmission to Subscribers,
the actual data resides on the Post Office. The value of the regex
element is the session forked by the Dispatcher to Queue the work for Subscriptions. It also
happens to be a value for a FileName pattern used by the
PostOffice. All files persisted by the PostOffice in relation to a single Client Request
have names that start with this value.
All files sent by the PostOffice to Subscribers will also have names beginning with this value.
Path information on the Subscriber and Address information used to get to the Subscriber
are in the element server and targetdirectory.
Depending on which Demo Track you are using ( Track 1 defaults or Data that you posted to
Forms used in connection with Track 2 ), refer to the information below and go to the
Subscriber computer using HTTP or FTP protocol to verify that the files were transferred
from your PC to the Subscriber via the PostOffice.
|
Verify Details Track 1A | Default properties will write your data to a Host and Directory that you can
verify by going to the following URL's :
D9AB91D9FFA9ABBin the regex element.
Comparing that to the URL's list of
files, you observe in the list a file with name=D9AB91D9FFA9ABBtest...
|
| Verify Details Track 2 |
Server IP is set at the time you submit the
"demo file exchange" form for the
Subscription that you want to use in the test.
For example, if you used the suggested server IP value in the form and then ran the demo,
your verification is made using the URL below:
user ID which you entered into the form. Once
there you should see your file(s) amoung the list. The rules for identifying your
data files according to the new name they were assigned during the PostOffice
portion of the process appear in the topic above
Verify Details Track 1A.
|
