IBM
Tivoli
Directory
Integrator
5.2:
Getting
Started
Guide
SC32-1382-00
���
IBM
Tivoli
Directory
Integrator
5.2:
Getting
Started
Guide
SC32-1382-00
���
Note
Before
using
this
information
and
the
product
it
supports,
read
the
general
information
under
Appendix
B,
“Notices,”
on
page
71.
First
Edition
(November
2003)
This
edition
applies
to
version
5,
release
2,
of
The
IBM
Tivoli
Directory
Integrator
and
to
all
subsequent
releases
and
modifications
until
otherwise
indicated
in
new
editions.
©
Copyright
International
Business
Machines
Corporation
2002,
2003.
All
rights
reserved.
US
Government
Users
Restricted
Rights
–
Use,
duplication
or
disclosure
restricted
by
GSA
ADP
Schedule
Contract
with
IBM
Corp.
Preface
This
document
contains
the
information
that
you
need
to
administer
the
IBM®
Tivoli®
Directory
Integrator.
Who
should
read
this
book
This
book
is
intended
for
system
administrators
and
users
and
anyone
interested
in
learning
more
about
IBM
Tivoli
Directory
Integrator.
Publications
Read
the
descriptions
of
the
IBM
Tivoli
Directory
Integrator
library
to
determine
which
publications
you
might
find
helpful.
After
you
determine
the
publications
you
need,
refer
to
the
instructions
for
accessing
publications
online.
IBM
Tivoli
Directory
Integrator
library
The
publications
in
the
IBM
Tivoli
Directory
Integrator
library
are:
IBM
Tivoli
Directory
Integrator
5.2:
Readme
Contains
last-minute
information
about
IBM
Tivoli
Directory
Integrator
5.2.
IBM
Tivoli
Directory
Integrator
5.2:
Getting
Started
Guide
A
brief
tutorial
and
introduction
to
IBM
Tivoli
Directory
Integrator
5.2.
IBM
Tivoli
Directory
Integrator
5.2:
Administrator
Guide
Includes
complete
information
for
installing
the
IBM
Tivoli
Directory
Integrator.
Includes
information
about
migrating
from
a
previous
version
of
IBM
Tivoli
Directory
Integrator.
Includes
information
about
configuring
the
logging
functionality
of
IBM
Tivoli
Directory
Integrator.
IBM
Tivoli
Directory
Integrator
5.2:
Users
Guide
Contains
information
about
using
the
IBM
Tivoli
Directory
Integrator
5.2
tool.
Contains
instructions
for
designing
solutions
using
the
IBM
Tivoli
Directory
Integrator
tool
(ibmditk)
or
running
the
ready-made
solutions
from
the
command
line
(ibmdisrv).
Also
provides
information
about
interfaces,
concepts
and
AssemblyLine/EventHandler
creation
and
management.
Includes
examples
to
create
interaction
and
hands-on
learning
of
IBM
Tivoli
Directory
Integrator
5.2.
IBM
Tivoli
Directory
Integrator
5.2:
Reference
Guide
Contains
detailed
information
about
the
individual
components
of
IBM
Tivoli
Directory
Integrator
5.2
AssemblyLine
(Connectors,
EventHandlers,
Parsers,
Plug-ins,
and
so
forth).
Related
publications
Information
related
to
the
IBM
Tivoli
Directory
Integrator
is
available
in
the
following
publications:
v
The
IBM
Tivoli
Directory
Integrator
5.2
uses
the
JNDI
client
from
Sun
Microsystems.
For
information
about
the
JNDI
client,
refer
to
the
Java™
Naming
and
Directory
Interface™
1.2.1
Specification
on
the
Sun
Microsystems
Web
site
at
http://java.sun.com/products/jndi/1.2/javadoc/index.html
.
v
The
Tivoli
Software
Library
provides
a
variety
of
Tivoli
publications
such
as
white
papers,
datasheets,
demonstrations,
redbooks,
and
announcement
letters.
©
Copyright
IBM
Corp.
2002,
2003
iii
The
Tivoli
Software
Library
is
available
on
the
Web
at:
http://www.ibm.com/software/tivoli/library/
v
The
Tivoli
Software
Glossary
includes
definitions
for
many
of
the
technical
terms
related
to
Tivoli
software.
The
Tivoli
Software
Glossary
is
available,
in
English
only,
from
the
Glossary
link
on
the
left
side
of
the
Tivoli
Software
Library
Web
page
http://www.ibm.com/software/tivoli/library/
Accessing
publications
online
The
publications
for
this
product
are
available
online
in
Portable
Document
Format
(PDF)
or
Hypertext
Markup
Language
(HTML)
format,
or
both
in
the
Tivoli
software
library:
http://www.ibm.com/software/tivoli/library.
To
locate
product
publications
in
the
library,
click
the
Product
manuals
link
on
the
left
side
of
the
Library
page.
Then,
locate
and
click
the
name
of
the
product
on
the
Tivoli
software
information
center
page.
Information
is
organized
by
product
and
includes
READMEs,
installation
guides,
user’s
guides,
administrator’s
guides,
and
developer’s
references
as
necessary.
Note:
To
ensure
proper
printing
of
publications,
select
the
Fit
to
page
check
box
in
the
Adobe
Acrobat
window
(which
is
available
when
you
click
File->Print).
Accessibility
Accessibility
features
help
a
user
who
has
a
physical
disability,
such
as
restricted
mobility
or
limited
vision,
to
use
software
products
successfully.
With
this
product,
you
can
use
assistive
technologies
to
hear
and
navigate
the
interface.
After
installation
you
also
can
use
the
keyboard
instead
of
the
mouse
to
operate
all
features
of
the
graphical
user
interface.
Contacting
software
support
Before
contacting
IBM
Tivoli
Software
support
with
a
problem,
refer
to
IBM
System
Management
and
Tivoli
software
Web
site
at:
http://www.ibm.com/software/sysmgmt/products/support/
If
you
need
additional
help,
contact
software
support
by
using
the
methods
described
in
the
IBM
Software
Support
Guide
at
the
following
Web
site:
http://techsupport.services.ibm.com/guides/handbook.html
The
guide
provides
the
following
information:
v
Registration
and
eligibility
requirements
for
receiving
support
v
Telephone
numbers
and
addresses,
depending
on
the
country
in
which
you
are
located
v
A
list
of
information
you
must
gather
before
contacting
customer
support
iv
IBM
Tivoli
Directory
Integrator
5.2:
Getting
Started
Guide
Contents
Preface
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. iii
Who
should
read
this
book
.
.
.
.
.
.
.
.
. iii
Publications
.
.
.
.
.
.
.
.
.
.
.
.
.
. iii
IBM
Tivoli
Directory
Integrator
library
.
.
.
. iii
Related
publications
.
.
.
.
.
.
.
.
.
. iii
Accessing
publications
online
.
.
.
.
.
.
. iv
Accessibility
.
.
.
.
.
.
.
.
.
.
.
.
.
. iv
Contacting
software
support
.
.
.
.
.
.
.
.
. iv
Chapter
1.
Introduction
.
.
.
.
.
.
.
. 1
About
this
manual
.
.
.
.
.
.
.
.
.
.
.
. 1
Scripting
languages
.
.
.
.
.
.
.
.
.
.
.
. 2
Installing
IBM
Tivoli
Directory
Integrator
.
.
.
.
. 2
Installing
the
tutorial
files
.
.
.
.
.
.
.
.
.
. 2
Chapter
2.
Simplify
and
solve
.
.
.
.
. 3
How
do
you
eat
an
elephant?
.
.
.
.
.
.
.
.
. 3
Integration
is
communication
.
.
.
.
.
.
.
.
. 3
Architecture
.
.
.
.
.
.
.
.
.
.
.
.
.
. 6
AssemblyLines
.
.
.
.
.
.
.
.
.
.
.
.
. 6
Connectors
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 7
Parsers
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 8
EventHandlers
.
.
.
.
.
.
.
.
.
.
.
.
.
. 8
Chapter
3.
Introducing
IBM
Tivoli
Directory
Integrator
.
.
.
.
.
.
.
.
. 11
Rapid
integration
development
.
.
.
.
.
.
.
. 11
Creating
a
new
Config
.
.
.
.
.
.
.
.
.
.
. 12
Creating
an
AssemblyLine
.
.
.
.
.
.
.
.
. 14
Adding
the
Input
Connector
.
.
.
.
.
.
.
.
. 17
Mapping
Attributes
Into
The
AssemblyLine
.
.
. 24
Adding
the
Output
Connector
.
.
.
.
.
.
.
. 31
Running
your
AssemblyLine
.
.
.
.
.
.
.
. 36
Working
with
Hooks
.
.
.
.
.
.
.
.
.
.
. 39
Schema
conversion
.
.
.
.
.
.
.
.
.
.
.
. 42
Adding
the
Join
Connector
.
.
.
.
.
.
.
.
. 44
Setting
up
Link
Criteria
.
.
.
.
.
.
.
.
.
. 47
EventHandlers
.
.
.
.
.
.
.
.
.
.
.
.
. 53
Final
thoughts
.
.
.
.
.
.
.
.
.
.
.
.
. 67
Appendix
A.
index.html
and
OtherPage.html
.
.
.
.
.
.
.
.
.
.
. 69
index.html
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 69
OtherPage.html
.
.
.
.
.
.
.
.
.
.
.
.
. 69
Appendix
B.
Notices
.
.
.
.
.
.
.
.
. 71
Third-party
component
statements
.
.
.
.
.
. 73
Apache
statement
.
.
.
.
.
.
.
.
.
.
. 73
Rhino
statement
.
.
.
.
.
.
.
.
.
.
.
. 74
Trademarks
.
.
.
.
.
.
.
.
.
.
.
.
.
. 74
©
Copyright
IBM
Corp.
2002,
2003
v
vi
IBM
Tivoli
Directory
Integrator
5.2:
Getting
Started
Guide
Chapter
1.
Introduction
About
this
manual
This
book
is
a
simple
introduction
to
a
simple
system.
Make
no
mistake,
the
word
simple
is
used
here
in
its
most
positive
and
powerful
context,
because
the
best
way
to
wrap
your
mind
around
a
complex
problem
is
to
simplify
it.
Break
it
down
into
more
manageable
pieces,
and
then
master
those
constituent
parts.
Divide
and
conquer.
This
is
a
technique
that
you
instinctively
use
to
solve
everyday
problems,
and
which
is
equally
relevant
for
engineering
information
exchange
across
an
office,
an
enterprise
or
the
globe.
IBM
Tivoli
Directory
Integrator
is
designed
and
built
on
the
premise
that
integration
problems
can
be
broken
down
into
three
basic
components:
v
The
systems
involved
in
the
communication
v
The
data
flows
between
these
systems
v
And
the
events
which
trigger
the
data
flows
With
IBM
Tivoli
Directory
Integrator
you
turn
this
atomic
understanding
of
the
integration
problem
directly
into
the
solution.
You
can
build
your
solution
incrementally,
one
flow
at
a
time,
with
continuous
feedback
and
verification.
This
means
that
integration
projects
become
easier
to
estimate
and
plan.
Sometimes
planning
can
even
be
reduced
to
simply
counting
and
determining
the
cost
of
the
individual
data
flows
to
be
implemented.
And
since
you
are
developing
the
solution
flow-by-flow
visually
and
interactively,
you
can
report
(and
demonstrate)
progress
to
both
project
and
corporate
management
at
any
time.
IBM
Tivoli
Directory
Integrator
manages
the
technicalities
of
connecting
to
and
interacting
with
the
various
data
sources
that
you
want
to
integrate,
abstracting
away
the
details
of
their
APIs,
transports,
protocols
and
formats.
Instead
of
focusing
on
data,
IBM
Tivoli
Directory
Integrator
lifts
your
view
to
the
information
level,
enabling
you
to
concentrate
on
the
transformation,
filtering
and
other
business
logic
required
to
perform
each
exchange.
IBM
Tivoli
Directory
Integrator
enables
you
to
build
libraries
of
components
and
business
logic
that
can
be
maintained,
extended
and
reused
to
address
new
challenges.
Development
projects
across
your
organization
can
all
share
IBM
Tivoli
Directory
Integrator
assets,
resulting
in
independent
projects
(even
point
solutions)
that
immediately
fit
into
a
coherent
integrated
infrastructure.
This
approach
results
in
a
more
rational
and
predictable
use
of
resources,
as
you
bring
your
data
source
and
technology
experts
in
at
the
very
start
of
a
project
in
order
to
set
up
your
libraries.
When
in
place,
these
integration
assets
are
available
across
the
network,
letting
you
leverage
them
to
create
new
solutions
and
enhance
existing
ones.
This
document
gives
you
an
introduction
to
this
approach,
as
well
as
information
about
how
to
tap
into
the
radical
and
elegant
simplicity
of
IBM
Tivoli
Directory
Integrator.
©
Copyright
IBM
Corp.
2002,
2003
1
Scripting
languages
IBM
Tivoli
Directory
Integrator
provides
an
elegant
and
intuitive
point-and-shoot
environment
for
rapidly
building
the
framework
of
your
integration
solution.
However,
you
might
soon
want
to
add
more
advanced
data
manipulation
and
transformation
logic,
as
well
as
business
rules
for
filtering
your
data
and
controlling
the
behavior
of
your
data
flows.
All
of
this
is
done
by
writing
script
in
your
solution.
Because,
IBM
Tivoli
Directory
Integrator
uses
the
Beans
Scripting
Framework,
you
can
choose
from
a
wide
selection
of
scripting
languages,
including
JavaScript™,
VBScript
and
PerlScript.
For
more
information
about
scripting
languages,
see
the
IBM
Tivoli
Directory
Integrator
5.2:
Reference
Guide.
Installing
IBM
Tivoli
Directory
Integrator
IBM
Tivoli
Directory
Integrator
is
a
light
,
rapidly
deployed
integration
middleware.
Unlike
traditional
middleware,
IBM
Tivoli
Directory
Integrator
installs
in
minutes
and
you
can
begin
building,
testing
and
deploying
solutions
immediately.
The
system
runs
on
a
wide
variety
of
platforms,
including
Windows®
and
a
number
of
UNIX®
and
Linux
versions.
For
more
information
about
installing
the
IBM
Tivoli
Directory
Integrator,
please
see
″IBM
Tivoli
Directory
Integrator
installation
instructions″
in
the
IBM
Tivoli
Directory
Integrator
5.2:
Administrator
Guide.
Installing
the
tutorial
files
To
work
with
the
examples
in
this
manual,
you
need
the
Tutorial
data
files
(although,
you
can
reproduce
them
from
the
text
in
this
manual).
To
access
these
example
files,
go
to
the
root_directory/examples
directory
in
the
installation
directories.
root_directory
indicates
the
directory
where
IBM
Tivoli
Directory
Integrator
is
installed.
2
IBM
Tivoli
Directory
Integrator
5.2:
Getting
Started
Guide
Chapter
2.
Simplify
and
solve
How
do
you
eat
an
elephant?
The
answer
is,
one
bite
at
a
time.
This
is
also
the
best
approach
for
digesting
large
integration
and
systems
deployment
projects.
The
key
to
success
is
to
reduce
complexity
by
breaking
the
problem
up
into
smaller,
manageable
pieces.
This
means
starting
with
a
portion
of
the
overall
solution,
preferably
one
that
can
be
completed
in
a
week
or
two.
Ideally,
this
is
a
piece
that
can
be
independently
put
into
production.
That
way,
it’s
already
providing
return
on
investment
while
you
tackle
the
rest
of
the
solution.
When
you
have
isolated
the
piece
you
are
going
to
work
with,
simplify
it
further
by
focusing
in
on
the
basic
units
of
communication
(the
data
flows
themselves).
You
are
now
poised
to
start
implementing
them.
Integration
development
is
done
with
IBM
Tivoli
Directory
Integrator
through
a
series
of
try-test-refine
cycles,
making
the
process
an
iterative,
even
exploratory
one.
This
not
only
helps
you
to
discover
more
about
your
own
installation,
but
also
lets
you
grow
your
integration
solution
as
your
understanding
of
the
problem
set
and
its
impact
on
your
infrastructure
grows.
A
great
way
to
get
a
good
mental
picture
of
the
problem
at
hand
is
to
make
a
picture
of
it.
Using
a
pencil
and
a
piece
of
paper,
sketch
out
a
flow
diagram
that
maps
out
the
solution
in
broad
strokes.
This
exercise
not
only
helps
you
to
visualize
the
scope
of
the
task,
it
serves
as
a
blueprint
for
implementing
the
task
in
IBM
Tivoli
Directory
Integrator.
Integration
is
communication
Integration
problems
are
all
about
communication,
and
as
such
can
typically
be
broken
down
into
three
basic
parts:
v
The
systems
and
devices
that
communicate
v
The
flows
of
data
between
these
systems
v
The
events
that
trigger
the
data
flows
These
constituent
elements
of
a
communications
scenario
can
be
described
as
follows:
Data
Sources
These
are
the
data
repositories,
systems
and
devices
that
talk
to
each
other.
For
example:
v
The
Enterprise
Directory
you’re
implementing
or
trying
to
maintain
v
Your
CRM
application
v
The
office
phone
system
v
The
Access
database
with
the
list
of
company
equipment
and
to
whom
the
equipment
has
been
issued
Data
sources
represent
a
wide
variety
of
systems
and
repositories,
such
as
databases
(for
example,
DB2®,
Oracle,
SQL
Server),
directories
(for
example,
iPlanet,
IBM
Directory
Server,
Domino™,
eDirectory
and
Active
©
Copyright
IBM
Corp.
2002,
2003
3
Directory),
directory
services
(Exchange),
files
(for
example,
XML,
LDIF
or
SOAP
documents),
specially
formatted
e-mail,
or
any
number
of
interfacing
mechanisms
that
internal
systems
and
external
business
partners
use
to
communicate
with
your
information
assets
and
services.
Data
Flows
These
are
the
threads
of
the
communications
and
their
content,
and
are
usually
drawn
as
arrows
which
point
in
the
direction
of
data
movement.
Each
data
flow
represents
a
communication
between
two
or
more
systems.
However,
for
a
conversation
to
be
meaningful
to
all
participants,
everyone
involved
must
understand
what
is
being
communicated.
You
can
probably
expect
the
data
sources
to
represent
their
data
content
in
different
ways.
One
system
might
represent
a
telephone
number
as
textual
information,
including
the
dashes
and
parentheses
used
to
make
the
number
easier
to
read.
Another
system
might
store
the
telephone
numbers
as
numerical
data.
If
these
two
systems
are
to
communicate
this
data,
then
the
information
must
be
translated
during
the
conversation.
Furthermore,
the
information
in
one
source
might
not
be
complete,
and
might
need
to
be
augmented
with
attributes
from
other
data
sources.
Furthermore,
only
parts
of
the
data
in
the
flow
might
be
relevant
to
receiving
systems.
Therefore
a
data
flow
must
also
include
the
mapping,
filtering
and
transformation
of
information,
shifting
its
context
from
input
sources
to
that
of
the
destination
systems.
Events
Events
can
be
described
as
the
circumstances
dictate
when
one
set
of
data
sources
communicates
with
another.
One
example
is
whenever
an
employee
is
added
to,
updated
within
or
deleted
from
the
HR
system.
Another
example
is
when
the
access
control
system
detects
a
keycard
being
used
in
a
restricted
area.
An
event
can
also
be
based
on
a
calendar
or
a
clock-based
timer,
for
example,
starting
communications
at
every
10
minutes,
or
at
12:00
midnight
on
Sundays.
It
can
also
be
a
manually
initiated
one-off
event,
such
as
populating
a
directory
or
washing
the
data
in
a
system.
Events
are
usually
tied
to
a
data
source,
and
are
related
to
the
data
flows
that
are
triggered
when
the
specified
set
of
circumstances
arise.
Each
of
these
elements
is
handled
by
IBM
Tivoli
Directory
Integrator
using
its
three
types
of
components:
Connectors,
Parsers
and
EventHandlers.
v
Connectors
are
components
that
connect
to
and
access
data
in
a
data
source.
For
example,
you
can
use
a
JDBC
Connector
to
read
and
write
to
an
SQL
database,
while
an
LDAP
Connector
enables
us
to
access
a
directory.
Some
types
of
data
sources
do
not
store
data
as
structured
objects
(records,
entries,
and
so
forth),
using
bytestreams
instead.
Two
examples
are
data
over
IP
and
flat
files.
That’s
where
Parsers
come
in,
turning
bytestreams
into
structured
information,
or
structured
information
into
bytestreams.
v
Data
flows
are
implemented
by
attaching
one
or
more
Connectors
together
(associating
Connectors
with
Parsers
where
necessary).
v
Finally,
the
EventHandlers
can
be
configured
to
pick
up
change
notifications
in
connected
systems
(such
as
directories
or
POP3/IMAP
mailboxes)
and
then
dispatch
these
events
to
the
designated
AssemblyLines.
4
IBM
Tivoli
Directory
Integrator
5.2:
Getting
Started
Guide
Before
you
dive
deeper
into
how
these
components
work,
you
need
to
get
an
overview
of
the
data
flows
you
want
to
implement.
As
mentioned
previously,
a
good
way
to
do
this
is
to
create
a
flow
diagram.
There
are
many
diagramming
conventions
and
styles
available
to
choose
from,
but
the
actual
shape
and
type
of
symbols
is
less
important
than
your
understanding
of
the
problem.
Use
boxes
or
balls
or
bubbles
or
whatever
you’re
comfortable
with,
but
be
consistent
and
be
sure
to
label
everything
clearly
and
legibly.
That
way,
when
you
look
at
your
diagram
in
a
couple
of
months
(or
when
someone
else
does),
it
still
makes
sense.
An
output
data
source
(DS3)
gets
data
from
an
initial
data
source
(DS1).
Along
the
way,
the
data
flow
collects
information
from
a
second
data
source
(DS2).
In
IBM
Tivoli
Directory
Integrator,
such
a
data
flow
is
referred
to
as
an
AssemblyLine.
It’s
important
to
understand
that
each
AssemblyLine
implements
a
single
uni-directional
data
flow.
If
you
want
to
do
bi-directional
synchronization
between
two
or
more
data
sources,
then
you
must
use
a
separate
AssemblyLine
for
handling
the
flow
in
each
direction.
The
reason
for
this
is
that
the
form
and
content
of
the
data,
as
well
as
the
operations
carried
out
on
it,
most
likely
are
different
for
each
direction.
Note:
IBM
Tivoli
Directory
Integrator
provides
everything
needed
to
create
request-response
information
solutions
such
as
Web
Services.Although
there
are
no
limits
to
the
number
of
Connectors
that
an
AssemblyLine
can
contain,
the
AssemblyLines
must
contain
as
few
Connectors
as
possible
(for
example,
one
per
data
source
participating
in
the
flow),
while
at
the
same
time
including
enough
components
and
script
logic
to
make
the
AssemblyLine
as
autonomous
as
possible.
The
reasoning
behind
this
is
to
make
the
AssemblyLine
easy
to
understand
and
maintain.
It
also
results
in
simpler,
faster
and
more
scalable
solutions.
The
IBM
Tivoli
Directory
Integrator
philosophy
is
about
dealing
with
the
flows
one
at
a
time,
simplifying
the
problem
set,
so
let’s
start
on
the
flow
going
from
DS1
to
DS3.
How
data
is
organized
can
differ
greatly
from
system
to
system:
v
Databases
typically
store
information
in
records
with
a
fixed
number
of
fields.
v
Directories,
on
the
other
hand,
work
with
variable
objects
called
entries.
v
Other
systems
can
use
messages
or
key-value
pairs.
IBM
Tivoli
Directory
Integrator
simplifies
this
issue
by
collecting
and
storing
all
types
of
information
in
a
powerful
and
flexible
data
container
called
an
Entry.
In
turn,
the
data
values
themselves
are
kept
in
objects
called
Attributes
that
the
Entry
holds
and
manages.
Another
potential
problem
is
that
these
sources
use
different
types
to
represent
stored
values.
IBM
Tivoli
Directory
Integrator
takes
care
of
this
for
you
as
well.
Everything
that
gets
pulled
into
the
data
flow
is
converted
to
a
format
consistent
with
predefined
rules
(Java
objects).
As
a
result,
your
business
rules
and
transformation
logic
do
not
have
to
deal
with
type
conflicts.
When
the
data
is
ready
for
output,
IBM
Tivoli
Directory
Integrator
converts
it
back
to
the
relevant
data
source-specific
types.
In
order
to
complete
the
visualization
of
the
data
flow,
record
how
the
attributes
of
the
input
data
source
are
mapped
(and
possibly
modified)
to
the
attributes
of
the
destination
system.
For
example,
DS3
might
look
like
the
following:
Chapter
2.
Simplify
and
solve
5
First
=DS1.First
Last
=DS1.Last
FullName
=DS1.First+"
"+DS1.Last
Title
=DS1.Title
=<compute_from_name>
To
keep
the
example
simple,
use
a
comma-separated
value
file
as
the
DS1
that
contains
the
fields
First,
Last
and
Title.
Your
output
data
source
(DS3)
is
an
XML
document.
Now
that
you
have
a
good
representation
of
the
solution,
let’s
take
a
look
at
how
IBM
Tivoli
Directory
Integrator
handles
data
flows.
Architecture
The
architecture
of
IBM
Tivoli
Directory
Integrator
is
divided
into
two
parts:
v
The
core
system,
where
most
of
the
system’s
functionality
is
provided.
The
IBM
Tivoli
Directory
Integrator
core
handles
log
files,
error
detection
and
dispatching,
and
data
flow
run
parameters.
This
is
also
where
your
customized
configuration
and
business
logic
is
maintained.
v
The
components,
which
serve
to
abstract
away
the
technical
details
of
the
data
systems
and
formats
that
you
want
to
work
with.
IBM
Tivoli
Directory
Integrator
provides
you
with
three
types
of
components:
–
Connectors
–
Parsers
–
EventHandlers
Since
each
is
wrapped
by
core
functionality
which
handles
things
such
as
integration
flow
control
and
customization,
the
components
themselves
can
remain
small
and
lightweight.
For
example,
if
you
want
to
implement
your
own
Parser,
you
only
have
to
provide
two
functions:
one
for
interpreting
the
structure
of
an
incoming
bytestream,
and
one
for
adding
structure
to
an
outgoing
bytestream.
If
you
take
a
look
in
the
jars
sub-directory
of
IBM
Tivoli
Directory
Integrator
you
see
how
lightweight
the
standard
components
are,
making
them
easy
to
create
and
extend.
This
core/component
design
makes
IBM
Tivoli
Directory
Integrator
easily
extensible.
It
also
means
that
you
can
rapidly
build
the
framework
of
your
solutions
by
selecting
the
relevant
components
and
clicking
them
into
place.
Components
are
interchangeable
and
can
be
swapped
out
without
affecting
the
customized
logic
and
configured
behavior
of
your
data
flows.
This
means
that
you
can
build
integration
solutions
that
are
quickly
augmented
and
extended,
while
keeping
them
less
vulnerable
to
changes
in
the
underlying
infrastructure.
AssemblyLines
The
data
flow
arrows
in
the
diagram
translate
in
IBM
Tivoli
Directory
Integrator
to
AssemblyLines,
which
work
in
a
similar
fashion
to
real-world
industrial
assembly
lines.
Real-world
assembly
lines
are
made
up
of
a
number
of
specialized
machines
that
differ
in
both
function
and
construction,
but
have
one
significant
attribute
in
common:
they
can
be
linked
together
to
form
a
continuous
path
from
input
sources
to
output.
6
IBM
Tivoli
Directory
Integrator
5.2:
Getting
Started
Guide
An
assembly
line
generally
has
one
or
more
input
units
designed
to
accept
whatever
the
raw
materials
needed
for
production
might
be,
for
example,
fish
fillets,
cola
syrup,
car
parts,
and
so
forth.
These
ingredients
are
processed
and
merged
together.
Sometimes
by-products
are
extracted
from
the
assembly
line
along
the
way.
At
the
end
of
the
production
line,
the
finished
goods
are
delivered
to
waiting
output
units.
If
a
production
crew
gets
the
order
to
produce
something
else,
they
break
the
line
down,
keeping
the
machines
that
are
still
relevant
to
the
new
order.
New
units
are
connected
in
the
right
places,
the
line
is
adjusted
and
production
starts
again.
The
IBM
Tivoli
Directory
Integrator
AssemblyLines
work
in
much
the
same
way.
The
IBM
Tivoli
Directory
Integrator
AssemblyLines
receive
information
from
various
input
units,
perform
operations
on
this
input
and
then
convey
the
finished
product
through
output
units.
IBM
Tivoli
Directory
Integrator
AssemblyLines
work
on
one
item
at
a
time,
for
example,
one
data
record,
directory
entry,
registry
key,
and
so
forth.
Data
attributes
from
the
connected
input
sources
are
accumulated
in
a
Java
bucket
(called
the
work
object)
and
scripts
can
be
added
that
work
with
this
information:
verifying
data
content,
computing
new
attributes
and
values,
as
well
as
changing
existing
ones,
until
the
data
is
ready
for
delivery
from
the
line
into
one
or
more
output
sources.
The
input
and
output
units
of
an
IBM
Tivoli
Directory
Integrator
AssemblyLine
are
called
Connectors,
and
each
Connector
is
linked
into
a
data
store.
Connectors
tie
the
data
flow
to
the
outside
world,
and
are
also
where
data
transformation
and
aggregation
takes
place.
They
are
also
where
you
can
layer
in
your
business,
security
and
identity
management
logic.
Connectors
Connectors
are
like
puzzle
pieces
that
click
together,
while
at
the
same
time
linking
to
a
specific
data
source.
Each
time
you
select
one
of
these
puzzle
pieces
and
add
it
to
an
AssemblyLine,
you
must
do
the
following:
1.
Choose
the
type
of
Connector.
2.
Assign
the
Connector
its
role
in
the
data
flow.
This
is
called
the
Connector
mode,
and
it
tells
IBM
Tivoli
Directory
Integrator
how
to
use
the
Connector:
v
An
input
Connector
iterating
through
or
looking
up
information
in
its
source
v
An
output
Connector,
inserting,
updating
or
deleting
data
in
the
connected
system
or
device.
Note:
Data
must
be
pulled
out
of
input
sources
and
then
pushed
into
the
output
destinations.
That’s
what
Connectors
are
good
at.
You
can
change
both
the
type
and
mode
of
a
Connector
whenever
you
want
in
order
to
meet
changes
in
your
infrastructure,
or
in
the
goals
of
your
solution.
If
you’ve
planned
for
this
eventuality,
then
the
rest
of
the
AssemblyLine,
including
data
transformations
and
filtering,
are
not
impacted.
That’s
why
it’s
important
to
treat
each
Connector
as
a
black
box
that
either
delivers
data
into
the
mix,
or
extracts
some
of
it
to
send
to
a
data
source.
The
more
independent
each
Connector
is,
the
easier
your
solution
is
to
augment
and
maintain.
By
making
your
Connectors
as
autonomous
as
possible,
you
can
also
readily
transfer
them
to
your
Connector
Library
and
reuse
them
to
create
new
solutions
Chapter
2.
Simplify
and
solve
7
faster,
even
sharing
them
with
others.
Using
the
IBM
Tivoli
Directory
Integrator
library
feature
also
makes
maintaining
and
enhancing
your
Connectors
easier,
as
all
you
have
to
do
is
update
the
Connector
template
in
your
library,
and
all
AssemblyLines
derived
from
this
template
inherit
these
enhancements.
When
you
are
ready
to
put
your
solution
to
serious
work,
you
can
reconfigure
your
library
Connectors
to
connect
to
the
production
data
sources
instead
of
those
in
your
test
environment,
and
move
your
solution
from
lab
to
live
deployment
in
minutes.
Whenever
you
need
to
include
new
data
to
the
flow,
simply
add
the
relevant
Connector
to
the
AssemblyLine.
IBM
Tivoli
Directory
Integrator
gives
you
a
library
of
Connectors
to
choose
from,
such
as
LDAP,
JDBC,
Microsoft®
NT4
Domain,
Lotus®
Notes®
and
POP3/IMAP.
And
if
you
can’t
find
the
one
you
are
looking
for,
you
can
extend
an
existing
Connector
by
overriding
any
or
all
of
its
functions
using
one
of
the
leading
scripting
languages,
including
JavaScript,
VBScript
and
PerlScript.
You
can
even
create
your
own,
either
with
a
scripting
language
inside
the
Script
Connector
wrapper,
or
from
scratch
using
Java
or
C/C++.
Furthermore,
IBM
Tivoli
Directory
Integrator
supports
most
transport
protocols
and
mechanisms,
such
as
TCP/IP,
FTP,
HTTP
and
JMS
(MQ),
with
or
without
SSL,
or
other
encryption
mechanisms
to
secure
the
information
flow.
For
more
information
about
scripting
languages
and
on
how
to
create
your
own,
see
the
IBM
Tivoli
Directory
Integrator
5.2:
Reference
Guide.
Parsers
Even
unstructured
data,
such
as
text
files
or
bytestreams
coming
over
an
IP
port,
is
handled
quickly
and
simply
with
IBM
Tivoli
Directory
Integrator
by
passing
the
bytestream
through
one
or
more
Parsers.
Parsers
are
another
type
of
IBM
Tivoli
Directory
Integrator
component,
and
the
system
is
shipped
with
a
variety
of
Parsers,
including
LDIF,
DSML,
XML,
CSV
and
Fixed-length
field.
And
just
like
Connectors,
you
can
extend
and
modify
these,
as
well
as
create
your
own.
Continuing
with
the
example
from
page
5,
the
next
step
is
to
identify
the
data
sources.
Since
the
input
data
source
is
a
text
file
in
comma-separated
value
format,
you
use
the
File
System
Connector
paired
up
with
the
CSV
Parser.
Use
a
File
System
Connector
for
output
as
well,
but
this
time
choose
the
XML
Parser
in
order
to
format
the
file
as
an
XML
document.
Note:
The
examples
in
this
manual
have
been
created
on
a
UNIX
platform,
and
use
the
UNIX
pathname
conventions.
In
order
for
your
solution
to
be
platform
independent,
use
the
forward
slash
(
/
)
instead
of
the
backslash
character
(
\
)
in
your
pathnames,
for
example,
examples/Tutorial/Tutorial1.cfg.
This
works
on
both
Windows
and
UNIX/Linux
platforms.
EventHandlers
EventHandlers
are
the
third
type
of
IBM
Tivoli
Directory
Integrator
component,
and
provide
functionality
for
building
real-time
integration
solutions.
Like
Connectors,
EventHandlers
can
have
data
source
intelligence
which
can
enable
them
to
connect
to
a
system
or
service
and
wait
for
an
event
notification.
Examples
are
the
Mailbox
EventHandler
which
can
detect
when
new
messages
8
IBM
Tivoli
Directory
Integrator
5.2:
Getting
Started
Guide
arrive
in
a
POP3
or
IMAP
mailbox
or
the
LDAP
EventHandler
which
can
catch
changes
made
to
a
directory.
When
an
event
occurs,
the
EventHandler
stores
the
specifics
of
the
event
and
then
performs
logic
and
starts
AssemblyLines
according
to
the
condition/action
rules
that
you
set
up.
Sometime
Connectors
can
also
be
used
to
capture
events,
as
is
the
case
with
the
JMS
Connector
or
the
LDAP
Changelog
Connector,
both
of
which
can
be
configured
to
wait
until
new
data
appears
and
then
retrieve
it.
However,
since
the
EventHandler
operates
in
its
own
thread,
they
can
be
used
to
dispatch
events
to
multiple
AssemblyLines.
This
provides
a
cleaner
and
more
straightforward
method
of
filtering
and
handling
multiple
types
of
events
from
the
same
source
(for
example,
SOAP
or
Web
Services
calls).
EventHandlers
can
also
be
configured
for
Auto
Start,
meaning
that
if
you
start
up
a
server
with
the
Config,
these
EventHandlers
are
immediately
activated.
This
saves
you
from
having
to
specifically
name
the
AssemblyLines
to
run
in
the
command
line
parameters
to
the
server.
Now
that
you
have
been
introduced
to
the
components
that
IBM
Tivoli
Directory
Integrator
uses,
you
are
ready
to
build
the
AssemblyLine.
However,
before
you
continue,
you
need
an
input
file.
You
can
find
an
example
of
such
a
file
in
the
examples\Tutorial
sub-directory
in
the
directory
where
the
IBM
Tivoli
Directory
Integrator
was
installed,
or
you
can
create
your
own
with
a
text
editor.
The
included
sample
data
looks
like
the
following:
First;Last;Title
Bill;Sanderman;Chief
Scientist
Mick;Kamerun;CEO
Jill;Vox;CTO
Roger
Gregory;Highpeak;VP
Product
Development
Ernie;Hazzle;Chief
Evangelist
Peter;Belamy;Business
Support
Manager
This
file
is
called
People.csv
and
located
in
the
examples/Tutorial
folder
of
your
IBM
Tivoli
Directory
Integrator
installation
directory.
When
it
is
in
place,
you
are
ready
to
build
your
solution
using
IBM
Tivoli
Directory
Integrator.
Chapter
2.
Simplify
and
solve
9
10
IBM
Tivoli
Directory
Integrator
5.2:
Getting
Started
Guide
Chapter
3.
Introducing
IBM
Tivoli
Directory
Integrator
Rapid
integration
development
IBM
Tivoli
Directory
Integrator
is
actually
two
programs:
Toolkit
IDE
This
program
gives
you
a
graphical
interface
to
create,
test
and
debug
your
integration
solutions.
The
Toolkit
Integrated
Development
Environment
is
used
to
create
a
configuration
file
(called
a
Config
file)
that
is
started
by
the
runtime
engine.
The
Toolkit
IDE
executable
file
is
called
ibmditk.
Run-time
Server
Using
the
Config
you’ve
created
with
the
Toolkit
IDE
(and
which
is
stored
as
a
highly
structured
XML
document),
the
Run-time
Server
powers
the
integration
solution.
This
program
file
is
called
ibmdisrv,
and
you
can
deploy
your
solution
using
as
many
or
as
few
server
instances
as
you
want.
There
are
no
limitations
imposed
by
the
IBM
Tivoli
Directory
Integrator
technology.
Start
the
Toolkit
IDE.
After
a
moment
you
are
presented
with
the
Main
Screen.
From
here
you
can
create
a
new
Config,
which
you
can
revisit.
Note:
If
the
screen
you
see
is
different
from
the
screenshots
in
this
manual,
your
system
might
have
a
different
display
setting.
Do
the
following
to
change
the
display
setting:
1.
Click
File–>Edit
Preferences.
2.
Click
the
Appearance
tab.
3.
Click
the
Look
&
Feel
tab.
The
IBM
Tivoli
Directory
Integrator
window
is
resizeable.
If
the
screenshots
in
this
manual
do
not
match
your
own
experience,
try
changing
the
size
of
the
window
on
your
screen.
The
File–>Edit
Preferences
selection
opens
a
dialog
where
you
can
set
a
number
of
other
user
interface
parameters,
such
as
whether
the
main
button
toolbar
is
visible
or
not,
or
if
you
want
IBM
Tivoli
Directory
Integrator
to
use
the
Status
Bar
at
the
bottom
of
the
window.
At
the
top
of
the
screen
is
the
Main
Menu
and
the
button
toolbar.
©
Copyright
IBM
Corp.
2002,
2003
11
The
Main
Toolbar
provides
commands
for
creating
new
Configs,
opening
existing
ones
and
saving
your
current
work,
as
well
as
a
few
navigation
buttons.
These
same
commands
are
also
available
under
the
File
and
Window
menus,
where
you
also
find
the
Save
As
selection
for
saving
your
configuration
to
a
new
filename.
Creating
a
new
Config
IBM
Tivoli
Directory
Integrator
Configs
are
stored
as
XML
documents.
They
are
created
and
maintained
in
the
Toolkit
IDE
and
deployed
with
the
Server.
Each
Config
contains
the
AssemblyLines
that
a
Server
runs,
as
well
as
the
IBM
Tivoli
Directory
Integrator
components
that
make
up
these
lines.
The
Config
also
holds
user
preferences
such
as
colors
and
the
GUI
interface
style.
Note:
Configs
can
also
be
spread
over
several
files
and
stored
at
several
locations.
IBM
Tivoli
Directory
Integrator
assembles
its
configuration
dynamically
at
startup,
using
included
URLs
and
filepaths
that
you
have
specified.
This
means
that
you
can
create
and
maintain
corporate
settings
and
components
that
can
be
shared
by
many
server
configurations.
You
can
also
open
and
work
on
several
Configs
at
once,
dragging
and
dropping
components
between
them.
When
you
start
the
system
for
the
first
time,
you
are
presented
with
the
empty
screen
as
pictured
previously.
If
you
now
create
a
new
Config,
IBM
Tivoli
Directory
Integrator
asks
whether
you
want
to
create
the
default
Config,
called
rs.xml.
Instead
of
using
the
default
Config
name,
give
the
file
a
different
name.
Click
the
Create
a
New
Configuration
root
button,
or
use
the
File–>New
menu
12
IBM
Tivoli
Directory
Integrator
5.2:
Getting
Started
Guide
selection
to
create
a
Config
called
Tutorial1
(note
that
the
.xml
extension
is
added
for
you).
This
file
must
be
saved
in
the
examples/Tutorial
directory.
Note:
Pathnames
can
be
written
as
relative
to
the
directory
that
you
specified
when
installing
IBM
Tivoli
Directory
Integrator.
The
tree-view
at
the
left
side
of
the
screen
is
called
the
Config
Browser,
and
it
presents
you
with
a
set
of
folders
that
contain
various
aspects
of
your
solution.
The
folder
at
the
top
labelled
AssemblyLines
contains
the
AssemblyLines
you
create.
Just
below
it
are
three
folders
where
you
store
your
component
library
(one
folder
for
each
type
of
component).
This
enables
you
to
set
up
standard
Connectors
(for
example,
LDAP,
JDBC,
Notes,
and
so
forth)
with
configuration
and
behavior
parameters,
data
transformations
and
other
business
rules,
and
then
use
and
reuse
them
to
create
new
solutions.
Without
going
into
the
Toolkit
IDE
interface
in
great
detail,
here
is
the
general
layout
of
these
configuration
screens:
v
The
rest
of
the
screen
below
the
Toolbar
is
organized
into
panes.
The
Config
Browser
appears
at
the
left,
although
you
can
hide
and
show
this
pane
by
using
the
Toggle
Configuration
Tree
View
button
in
the
main
Toolbar,
or
clicking
on
the
arrows
at
the
top
of
the
divider
bar
next
to
the
Config
Browser.
To
the
right
of
this
pane
is
a
Details
area
which
changes
to
show
the
details
of
items
that
you
select
in
the
Config
Browser.
v
The
Details
pane
can
show
multiple
detailed
views,
opening
a
new
view
each
time
you
select
another
item
in
the
Config
Browser.
These
panes
can
be
accessed
using
the
Window
menu,
or
using
tabs
at
the
top
of
each
view
(depending
on
how
you
set
the
system’s
appearance).
v
Some
Details
panes
also
contain
lists
of
items.
The
Details
adapt
to
show
the
details
of
these
items
as
well
if
you
click
on
them.
v
Change
the
space
allocated
for
any
column
in
a
list
by
moving
the
mouse
cursor
over
the
boundary
between
columns
(the
cursor
indicates
that
you
can
do
so
by
changing
shape),
and
then
clicking
and
dragging
the
boundary
to
its
new
location.
v
At
the
top
of
each
Element
List
is
a
row
of
buttons
providing
the
set
of
operations
that
are
available
for
that
type
of
object
(in
the
case
of
the
data
flow
pane,
the
button
bar
is
underneath
the
Connectors
list).
The
list
of
available
operations
varies
from
pane
to
pane,
but
the
general
behavior
is
the
same:
select
an
entry
in
the
list,
and
then
click
the
button
(with
the
exception
of
any
Add
button,
where
you
do
not
need
to
select
anything
first).
v
You
can
select
several
elements
at
once
by
pressing
Shift
or
Ctrl
when
highlighting
items
in
lists.
v
You
can
drag
items
from
the
Config
Browser
into
your
AssemblyLines,
or
between
open
Configs.
Chapter
3.
Introducing
IBM
Tivoli
Directory
Integrator
13
Creating
an
AssemblyLine
The
first
thing
you
must
do
is
create
a
new
AssemblyLine.
Right-click
on
the
AssemblyLine
Folder.
From
the
context-sensitive
menu
that
pops
up,
select
New
AssemblyLine.
Name
this
AssemblyLine
CSVtoXML.
You
can
name
an
AssemblyLine
whatever
you
want,
but
it
is
important
to
use
a
naming
convention
that
helps
to
document
your
solution.
Note:
Use
of
special
characters
and
spaces
in
naming
AssemblyLines
or
IBM
Tivoli
Directory
Integrator
components
(such
as
Connectors
and
EventHandlers)
is
not
a
good
idea,
as
it
might
cause
problems
later
when
you
want
to
start
IBM
Tivoli
Directory
Integrator
Server
from
a
command
prompt
to
run
your
solution.
In
the
AssemblyLines,
components
and
other
Config
items
in
your
solution
are
available
in
your
solution
as
script
objects,
enabling
you
to
change
parameters
and
behavior
at
runtime.
This
means
that
you
want
to
use
names
that
enable
you
to
reference
these
objects
in
your
scripts.
IBM
Tivoli
Directory
Integrator
now
takes
you
to
the
AssemblyLine
screen.
Notice
that
this
new
screen
fills
the
previously-empty
configuration
pane.
Before
adding
the
Connectors,
take
a
quick
look
at
the
layout
of
the
AssemblyLine
screen:
14
IBM
Tivoli
Directory
Integrator
5.2:
Getting
Started
Guide
At
the
top
of
the
Detail
is
a
row
of
tabs,
each
associated
with
an
open
item
from
the
Config
Browser
(in
this
case,
the
new
AssemblyLine
Details
display).
In
the
title
of
each
tab
a
is
button
row
that
includes
a
Close
button
for
closing
this
details
screen.
Note:
ToolTips
appear
if
you
let
the
cursor
hover
over
any
of
the
buttons
in
the
Config
Tool.
Along
with
the
Close
button,
the
button
row
also
includes
two
other
buttons:
Run
Runs
the
current
AssemblyLine.
Run
Debug
IBM
Tivoli
Directory
Integrator
includes
a
data
flow
debugger
which
enables
you
to
step
through
the
AssemblyLine,
watching
the
data
being
transported
and
transformed
inside
the
AssemblyLine
as
control
is
passed
from
Connector
to
Connector.
The
white
box
on
the
left
side
of
the
AssemblyLine
Details
screen
is
the
Connector
List,
and
is
where
new
Connectors
appear
as
they
are
added
to
your
flow.
Below
Chapter
3.
Introducing
IBM
Tivoli
Directory
Integrator
15
the
Connector
List
is
the
Work
Entry
display.
This
enables
you
to
look
into
your
data
flow,
showing
you
at
all
times
the
data
attributes
being
read
in
from
the
connected
systems.
To
the
right
of
these
lists
is
where
the
details
of
the
currently
selected
Connector
are
displayed.
At
the
top
of
this
details
area
are
the
AssemblyLine
tabs.
These
tabs
give
you
access
to
various
aspects
of
this
data
flow:
These
tabs
are:
Hooks
The
AssemblyLine
Hooks
tab
enables
you
to
set
up
scripts
to
be
evaluated
or
started:
v
Before
Connectors
are
initialized
(enabling
you
to
reconfigure
your
Connectors
before
they
fire
up
their
connections)
v
After
Connector
initialization,
but
before
control
is
passed
to
the
first
Connector
v
After
the
last
Connector
finishes
v
When
the
AssemblyLine
is
asked
to
terminate
by
some
external
event
Data
Flow
Where
the
Connectors
are
created
and
maintained.
Config...
Gives
you
a
number
of
configuration
parameters
for
this
AssemblyLine.
Call/Return
This
is
where
you
can
specify
input
and
output
parameters
for
this
AssemblyLine
to
facilitate
calling
it
from
an
external
process
(for
example,
an
EventHandler).
If
you
click
the
Config...
tab,
you
see
that
you
can
set
parameters
such
as
scripting
language
you
want
to
use
in
this
AssemblyLine,
as
well
as
limiting
the
number
of
iterations
(useful
when
developing
and
testing
your
AssemblyLine
on
large
data
sets).
Note:
Regardless
of
which
scripting
language
you
select
to
use
in
your
AssemblyLine,
IBM
Tivoli
Directory
Integrator
lets
you
use
components
that
have
been
scripted
using
other
languages.
You
can
write
your
AssemblyLine
logic
in
JavaScript,
but
still
use
the
Connector
you
created
with
VBScript
as
well
as
your
PerlScript-based
Parser,
as
long
as
the
scripting
language
you
choose
is
supported
by
the
platform
on
which
you
are
running
IBM
Tivoli
Directory
Integrator.
Just
below
the
Connectors
box
is
the
Connector
List
button
bar,
offering
a
number
of
operations
for
working
with
your
Connectors:
16
IBM
Tivoli
Directory
Integrator
5.2:
Getting
Started
Guide
These
buttons
perform
the
following
actions:
Add
Connector
Adds
a
new
Connector
to
the
AssemblyLine.
This
can
also
be
done
by
dragging
a
pre-configured
Connector
from
the
Config
Browser
in
the
Connector
List.
Add
Script
Component
Adds
a
new
Connector
to
the
AssemblyLine.
A
Script
Component
is
a
block
of
script
that
you
can
place
in
an
AssemblyLine.
Delete
Removes
the
currently
selected
Connector
or
Script
Component
from
the
AssemblyLine.
Rename
Enables
you
to
change
the
name
of
the
currently
selected
item.
Up
Move
the
selected
Connector
or
Script
Component
up
one
spot
towards
the
start
of
the
AssemblyLine.
This
position
is
significant
since
the
AssemblyLine
runs
these
items
in
order
from
top
to
bottom.
Down
Move
the
selected
item
down
towards
the
end
of
list.
Copy
to
Library
Makes
a
copy
of
the
selected
Connector
and
drops
it
into
your
Connector
Library
(under
the
Connectors
folder
in
the
Config
Browser).
Adding
the
Input
Connector
Click
Add
to
create
the
first
Connector.
Call
this
Connector
InputPeople
and
click
on
the
drop-down
list
labeled
Connector.
Now
select
the
File
System
template
from
the
list,
which
shows
you
the
Connectors
delivered
with
the
system,
plus
any
that
are
registered
in
your
Connector
Library
(in
the
Connectors
folder).
Library
components
show
up
at
the
top
of
these
selection
drop-down
lists.
The
last
parameter
to
set
here
is
the
Connector
mode,
which
tells
the
AssemblyLine
what
the
role
of
this
Connector
is.
IBM
Tivoli
Directory
Integrator
has
six
Connector
modes:
Chapter
3.
Introducing
IBM
Tivoli
Directory
Integrator
17
AddOnly
This
mode
is
for
Connectors
that
only
add
new
information
to
the
data
source,
for
example,
writing
to
files,
populating
a
database
or
directory
for
the
first
time,
and
so
forth.
Delete
Delete
mode
causes
the
Connector
to
search
for
and
then
delete
the
specified
entry/record.
The
specification
for
keys
to
use
for
the
search
is
called
Link
Criteria.
Link
Criteria
must
be
specified
for
Connectors
performing
Lookup
and
Update
as
well,
since
these
modes
also
require
the
Connector
to
find
matching
data
in
the
connected
system.
Iterator
A
Connector
in
Iterator
mode
runs
through
the
data
source
(or
a
part
of
it,
for
example,
view
of
a
database
or
result
set
of
a
directory
search)
and
returns
the
entries
one
at
a
time
for
processing
in
the
AssemblyLine.
Connectors
in
Iterator
mode
are
called
Iterators.
An
AssemblyLine
can
contain
more
than
one
Iterator,
and
these
are
started
in
succession,
the
second
Iterator
starting
up
when
the
first
one
reaches
the
end
of
its
data
set.
Lookup
This
mode
causes
the
Connector
to
find
and
return
entries
that
match
a
specified
search
criteria,
and
is
how
you
collect
information
into
a
data
flow.
Update
In
Update
mode,
a
Connector
tries
to
find
the
specified
entry
or
record.
If
the
Connector
succeeds,
existing
entries
are
modified
with
the
information
passed
to
the
Connector.
If
the
lookup
fails,
then
the
Connector
adds
the
information
instead.
Call/Return
This
is
a
very
special
mode
which
first
outputs
a
call
package
(such
as
a
SOAP
message
or
JMS
entry),
and
then
waits
for
a
reply.
If
you
want
to
use
the
Web
Service
Connector,
then
it
must
be
set
to
Call/Return
mode.
Note:
Not
all
modes
are
available
for
all
Connectors.
For
example,
if
you
are
working
with
a
flat
file,
then
Lookup,
Delete,
Update
and
Call/Return
are
not
supported
(unless
you
write
your
own
Connector,
or
enhance
an
existing
Connector).
There
is
no
limit
to
the
number
of
Connectors
that
an
AssemblyLine
can
hold,
and
you
can
also
have
as
many
of
the
same
type
as
needed,
even
connected
to
the
same
data
source.
This
is
even
necessary
in
some
cases.
For
example,
say
you
want
to
create
an
AssemblyLine
to
delete
all
the
records
in
a
data
source.
First
you
set
up
an
Iterator
(for
example,
a
Connector
in
Iterator
mode)
to
return
the
objects
that
you
want
to
delete.
Then
you
add
a
second
Connector
configured
to
work
with
the
same
system,
but
this
time
set
to
Delete
mode.
As
a
result,
the
AssemblyLine
loops
through
the
input
source,
passing
Entries
to
your
second
Connector
which
deletes
them.
Sometimes
it
is
undesirable
to
have
multiple
simultaneous
connections
to
the
same
data
source.
It
can
even
be
impossible
due
to
resource
locking
or
limits
imposed
by
software
licenses.
In
this
case,
you
can
tell
IBM
Tivoli
Directory
Integrator
to
reuse
an
existing
connection
when
you
add
a
new
Connector
by
scrolling
to
the
bottom
of
the
Connector
Type
drop-down
list.
Here
you
find
the
names
of
the
other
18
IBM
Tivoli
Directory
Integrator
5.2:
Getting
Started
Guide
Connectors
in
the
AssemblyLine,
appearing
with
an
at
symbol
(
@
)
in
front
of
their
names.
When
you
have
named
your
Connector
and
defined
type
and
mode
(see
“Adding
the
Input
Connector”
on
page
17),
click
OK
to
confirm
your
choices.
This
new
Connector
appears
in
the
AssemblyLine
Connector
List
at
the
left
hand
side
of
the
configuration
pane.
Notice
how
the
specifics
of
the
currently
selected
Connector
are
now
shown
in
the
Details
display
area
to
the
right
of
the
list.
Chapter
3.
Introducing
IBM
Tivoli
Directory
Integrator
19
If
you
later
want
to
change
the
type
of
Connector,
simply
click
on
the
Inherit
from:
link
at
the
top
of
the
details
pane
(next
to
the
State
drop-down)
and
choose
a
different
one.
The
first
thing
to
do
with
any
Connector
that
you
add
is
configure
it.
Make
sure
the
Config
tab
is
selected
in
the
Connector
details
display
(as
shown
above).
This
tab
is
closely
tied
to
the
data
source
you
are
connecting
to,
and
is
different
for
each
type
of
Connector.
The
File
System
Connector
that
you
just
added
requires
you
to
enter
the
path
of
the
file
you
want
to
write
to.
Using
the
Select...
button
next
to
the
File
Path
field
(you
might
have
to
scroll
the
pane
sideways,
depending
on
your
screen
resolution),
select
the
People.csv
file
in
the
examples/Tutorial
sub-directory.
20
IBM
Tivoli
Directory
Integrator
5.2:
Getting
Started
Guide
In
addition
to
the
pathname,
as
you
are
now
working
with
a
Connector
type
that
reads
and
writes
unstructured
data,
you
must
configure
a
Parser
as
well.
First
select
the
Parser
tab
(next
to
Connection
in
the
Connector
details
pane)
and
click
on
click
on
the
[parent]
link
in
the
Inherit
from:
box
at
the
bottom
of
the
tab
Chapter
3.
Introducing
IBM
Tivoli
Directory
Integrator
21
Another
way
to
set
Connector
inheritance
for
Parser,
as
well
as
other
characteristics,
is
by
using
the
Inheritance
dialog.
This
is
available
through
the
Inheritance
button
at
the
top
of
the
Connectors
details
pane.
Note:
If
you
had
a
pre-configured
Parser
in
your
library
then
you
can
drag
the
Parser
from
the
Config
Browser
and
drop
it
on
the
[parent]
link
in
the
Inherit
from:
box.
If
you
check
the
other
Connector
tabs,
note
that
all
the
various
aspects
of
a
Connector
can
be
inherited.
When
you
open
the
Inheritance
dialog,
select
the
CSV
Parser
22
IBM
Tivoli
Directory
Integrator
5.2:
Getting
Started
Guide
With
the
Parser
in
place,
select
the
Schema
tab.
Note
that
you
can
get
a
live
connection
to
the
data
source.
Click
the
Connect
button.
Click
the
Connect
button
at
the
top
of
this
tab
to
see
if
the
Connector
can
reach
the
data
source.
If
successful,
you
see
the
message
Connection
established.
Now
click
the
Next
button.
Each
time
you
click
the
Next
button,
you
are
telling
the
system
to
read
the
next
entry
in
the
data
source,
analyze
the
schema,
and
convert
the
source-specific
data
types
into
their
relevant
Java
objects
(such
as
strings,
date/time,
integers
and
so
forth).
The
data
retrieved
from
the
source
is
displayed
in
the
grid,
with
the
attribute
names,
the
Java
object
types
that
IBM
Tivoli
Directory
Integrator
is
converting
Chapter
3.
Introducing
IBM
Tivoli
Directory
Integrator
23
them
to,
and
the
actual
values
found
in
the
data
source.
Not
only
does
this
confirm
that
you
are
live
with
the
connected
system
or
file,
but
you
can
also
get
visual
control
of
the
data
being
read.
And
don’t
panic
if
IBM
Tivoli
Directory
Integrator
is
not
converting
the
underlying
data
types
as
you
want.
You
can
always
override
this
behavior
when
you
map
these
attributes
into
the
data
flow.
Mapping
Attributes
Into
The
AssemblyLine
Attribute
Mapping
is
the
operation
of
moving
information
from
the
data
source
to
the
data
flow
and
back
again.
You
saw
in
the
previous
step
how
IBM
Tivoli
Directory
Integrator
not
only
discovers
the
schema
for
you,
it
also
automatically
converts
the
data
to
Java
objects.
So
why
is
Attribute
Mapping
necessary?
Although
IBM
Tivoli
Directory
Integrator
has
made
the
data
available
to
you,
the
system
has
no
preconceptions
of
how
you
intend
to
use
it.
So
at
the
very
least,
you
must
select
those
attributes
you
want
to
use.
Some
of
the
attributes
might
have
to
be
computed,
combined,
created
or
converted
to
a
different
format
or
type
than
IBM
Tivoli
Directory
Integrator
has
chosen.
Typically,
this
is
handled
through
scripting
in
your
Attribute
Map.
To
get
an
idea
of
how
this
works
in
IBM
Tivoli
Directory
Integrator,
it
is
first
necessary
to
understand
that
Connectors
(in
fact,
all
components)
are
actually
made
up
of
two
parts:
v
The
Raw
Connector,
which
knows
how
to
communicate
with
and
interpret
responses
from
a
particular
data
source
v
The
generic
AssemblyLine
Connector
wrapper
that
enables
Connectors
to
plug
into
and
operate
in
the
IBM
Tivoli
Directory
Integrator
AssemblyLine
framework
Information
passed
to
or
from
a
data
source
is
kept
in
a
temporary
local
storage
object
inside
the
Raw
Connector.
It
is
from
here
that
you
map
attributes
into
the
AssemblyLine,
or
in
the
case
of
an
output
Connector,
map
them
out
to
the
data
output
source.
There
is
one
storage
object
(an
entry
object)
named
work,
which
is
used
by
the
entire
AssemblyLine
to
transport
data
values
(attributes).
In
addition,
each
Connector
has
a
local
entry
object
called
conn
which
it
uses
for
data
access
operations.
Moving
attributes
into
or
out
of
the
data
flow
is
called
mapping,
which
requires
moving
data
values
between
a
work
object
of
an
AssemblyLine,
and
the
conn
object
of
a
Connector.
As
mentioned
before,
you
can
change
the
data
source-specific
part
of
a
Connector
at
any
time
by
simply
changing
its
type
by
using
the
Inheritance
button
or
clicking
in
the
Inherits
from:
link
at
the
top
of
the
Connector
details
pane
(See
page
21)
.
However,
if
you
do
this,
you
might
also
have
to
change
the
Attribute
Map
so
your
business
rules
(script)
and
the
other
Connectors
in
your
AssemblyLine
still
have
access
to
the
attributes
that
they
need.
Your
Attribute
Map
might
also
be
affected
if
you
change
the
mode
of
your
Connector,
since
Connectors
in
an
input
mode
map
attributes
from
local
storage
in
the
Raw
Connector
(called
conn
in
your
scripts)
to
the
object
used
to
store
and
transport
data
in
the
AssemblyLine
(the
work
object).
Output
Connectors
map
attributes
the
other
way:
from
work
to
conn.
24
IBM
Tivoli
Directory
Integrator
5.2:
Getting
Started
Guide
In
your
example,
the
InputPeople
Connector
is
in
an
input
mode,
so
you
must
set
up
the
Input
Map.
Above
the
box
marked
Work
Attribute
is
the
Attribute
Map
toolbar,
enabling
you
to
work
with
attributes
in
the
Map.
The
area
to
the
right
of
the
Map
shows
you
the
list
of
attributes
discovered
by
the
Connector.
Here
you
can
select
one
or
more
attributes
and
then
drag
them
over
to
the
Attribute
Map.
You
can
select
several
elements
at
once
by
pressing
Shift
or
Ctrl
when
highlighting
items
in
lists.
Note:
It
is
possible
that
the
current
version
of
your
platform’s
GUI
interface
library
for
Java
has
a
problem
if
you
try
to
do
this.
In
that
case,
try
to
drag
and
drop
the
Attributes
on
top
of
the
list
header
that
says
Work
Attribute.
Notice
that
when
you
add
Attributes
to
the
Input
Map,
they
show
up
both
in
the
Work
Attribute
list
and
in
the
AssemblyLine’s
Work
Entry
box,
located
just
below
the
AssemblyLine
Connector
list.
Chapter
3.
Introducing
IBM
Tivoli
Directory
Integrator
25
The
Work
Entry
display
is
like
a
window
into
your
data
flow,
showing
you
which
attributes
are
being
mapped
in
from
connected
systems
(or
created
by
you),
as
well
as
the
name
of
the
Connectors
responsible
for
them.
After
you
complete
your
first
Connector’s
attribute
mapping,
it
looks
similar
to
the
following:
26
IBM
Tivoli
Directory
Integrator
5.2:
Getting
Started
Guide
What
you
have
set
up
now
is
a
simple,
one-to-one
mapping
from
the
Connector
to
the
Assembly
Line.
If
a
slightly
more
complex
mapping
is
required,
the
previously
mentioned
buttons
above
the
Work
Attribute
box
come
into
play.
For
example:
New
This
button
lets
you
manually
add
attributes
that
might
not
be
available
from
any
of
your
input
systems,
or
which
might
need
to
be
computed
from
existing
Attributes.
Delete
Removes
one
or
more
Attributes
from
the
Map.
Switch...
Toggles
between
the
pane
that
shows
available
Connector
attributes
and
one
that
displays
details
on
how
each
Attribute
in
the
Map
is
being
handled.
Rename...
Lets
you
change
the
name
of
the
Attribute.
Up
and
Down
arrows
These
buttons
enable
you
to
change
the
order
in
which
the
Connectors
are
run.
Remember,
the
AssemblyLine
starts
at
the
top
and
works
its
way
down
the
list.
Copy
to
library
When
you
have
a
Connector
that
is
configured
as
you
want
it,
you
can
then
copy
it
to
the
Connector
library
by
pressing
this
button.
As
you
select
Attributes
in
the
Input
Map,
mapping
details
are
displayed
for
that
Attribute.
At
the
top
of
the
details
pane
is
a
check
box
marked
Advanced.
As
you
Chapter
3.
Introducing
IBM
Tivoli
Directory
Integrator
27
can
see,
the
check
mark
is
absent,
indicating
that
you
are
using
Simple
mapping
for
the
attributes,
for
example,
that
IBM
Tivoli
Directory
Integrator
lifts
the
values
over
from
the
corresponding
Attributes
being
read
in
from
the
connected
system.
However,
if
you
want
to
convert
the
incoming
data,
or
otherwise
manipulate
these
values,
you
can
script
this
in
Advanced
mode.
Select
Advanced
mode
and
you
are
presented
with
a
script
editor
window
where
you
can
add
your
own
logic.
If
you
just
want
to
emulate
what
IBM
Tivoli
Directory
Integrator
already
does
for
you
in
Simple
mode,
the
box
might
contain
the
following
snippet
of
JavaScript
code:
ret.value
=
conn.getAttribute("First");
Note:
When
the
IBM
Tivoli
Directory
Integrator
does
simple
mapping,
it
copies
the
Attributes
as
outlined
above,
but
it
does
so
in
native
Java
instead
of
going
through
the
Scripting
Engine
that
is
invoked
when
you
select
Advanced
Mapping.
If
simple
mapping
is
all
you
need,
do
not
choose
Advanced
Mapping;
it
is
much
more
efficient
to
let
IBM
Tivoli
Directory
Integrator
handle
the
data
movement
involved.
28
IBM
Tivoli
Directory
Integrator
5.2:
Getting
Started
Guide
This
line
of
script
returns
the
attribute
named
First
from
local
storage
in
the
Raw
Connector
(the
conn
object).
Take
a
moment
to
look
at
the
IBM
Tivoli
Directory
Integrator
script
editor
window,
which
appears
wherever
you
need
to
write
scripts.
While
in
this
window,
you
have
a
number
of
typical
editor
features
(some
of
them
appearing
as
buttons
in
the
row
above
the
editor
window).
Arrow
keys
Moves
the
cursor
around
in
the
editor
window.
If
you
also
press
the
Shift
key
down
at
the
same
time,
you
can
select
text.
Press
Ctrl
and
the
left
and
right
arrow
keys
to
move
the
cursor
around,
one
word
at
a
time.
Press
both
Shift
and
Ctrl
to
select
whole
words
or
lines
of
script.
Cut
Cuts
the
selection
out
of
the
text.
This
function
is
available
as
both
the
first
button
from
the
left
in
the
row
above
the
editor
window,
as
well
as
using
the
Ctrl+X
keyboard
shortcut.
Copy
Copies
the
current
selection.
Copy
can
be
done
by
clicking
the
second
button
from
the
left
in
the
button
row,
or
pressing
Ctrl+C.
Paste
Pastes
text
into
the
script
at
the
current
position
of
the
cursor.
You
can
click
the
third
button
from
the
left
or
press
Ctrl+V.
Undo
Rolls
back
the
last
editing
operation.
This
is
the
fourth
button
from
the
left.
Redo
Reapplies
the
change
that
you
just
undid.
Redo
appears
in
the
button
row
to
the
right
of
the
Undo
button.
Chapter
3.
Introducing
IBM
Tivoli
Directory
Integrator
29
Find
Enables
you
to
search
for
text
in
your
script.
You
can
click
the
sixth
button
from
the
left
or
press
Ctrl+F.
Find
Again
Repeats
the
last
search.
Click
the
button
at
the
end
of
the
button
row,
or
press
Ctrl+G.
Toggle
line
wrapping
Turns
line
wrapping
on
and
off
in
the
editor
window.
Edit
buffer
with
external
editor
If
you
have
declared
an
external
editor
with
File–>Preferences
under
the
Editor
Settings
tab,
then
it
is
launched
when
you
press
this
button.
The
contents
of
the
script
edit
buffer
are
transferred
to
the
external
editor,
and
the
results
of
your
work
are
returned
to
IBM
Tivoli
Directory
Integrator
when
you
are
done.
Try
scripting
by
adding
an
Attribute
called
FullName
which
you
can
compute
using
values
from
other
attributes
read
in
from
the
input
source.
Click
the
New
button
at
the
top
of
the
Input
Map
In
the
dialog
box
that
appears,
enter
the
name
FullName
and
click
OK.
IBM
Tivoli
Directory
Integrator
automatically
tries
to
use
simple
mapping
to
retrieve
the
value
from
a
data
source
attribute
called
FullName.
This
doesn’t
work
because
this
information
is
not
available
in
the
input
file.
Instead,
you
need
to
select
this
new
entry
in
the
Attribute
Map
list
and
select
the
Advanced
mapping
checkbox.
This
gives
you
access
to
the
script
editor
window.
Here
is
the
script
that
you
use
to
create
the
value
for
this
attribute:
30
IBM
Tivoli
Directory
Integrator
5.2:
Getting
Started
Guide
gn
=
conn.getString("First");
sn
=
conn.getString("Last");
These
first
two
lines
retrieve
the
values
of
the
First
and
Last
attributes
as
Strings,
and
stores
them
in
two
new
variables
called
gn
and
sn,
respectively:
ret.value
=
gn
+
"
"
+
sn;
The
last
statement
returns
the
value
of
these
two
local
variables
concatenated
together
with
a
single
space
between
them.
Note:
You
can
create
this
attribute
in
the
output
Connector.
However,
because
you
need
it
in
the
AssemblyLine
later,
put
it
in
the
input
Connector.
The
input
feed
to
the
data
flow
is
now
finished.
You
are
connecting
to
the
input
source,
passing
the
bytestream
through
the
CSV
Parser
one
line
at
a
time,
converting
these
fields
to
Java
objects
and
moving
this
data
into
the
AssemblyLine.
It’s
time
to
add
the
output
Connector.
Adding
the
Output
Connector
Click
the
Add
button
in
the
button
toolbar
at
the
bottom
of
the
Connectors
list.
Name
the
Connector
XMLOutput.
Choose
the
File
System
type
again
and
set
the
Connector
mode
to
AddOnly
(the
only
output
mode
supported
by
the
File
System
Connector).
Chapter
3.
Introducing
IBM
Tivoli
Directory
Integrator
31
With
this
Connector
selected
in
the
Connectors
list,
configure
the
Connection
parameters
by
naming
the
output
file
Output.xml
and
writing
it
to
the
same
directory
where
the
input
file
was
located.
Now
click
on
the
Parser
tab
and
select
the
XML
Parser.
32
IBM
Tivoli
Directory
Integrator
5.2:
Getting
Started
Guide
Now
all
that
is
left
to
do
is
to
tell
the
XMLOutput
Connector
which
attributes
to
write
to
the
XML
document.
Click
the
Output
Map
tab
above
the
Connector
Attribute
box
(it
must
be
empty)
and
map
the
attributes
from
the
Assembly
Line
(for
example,
the
Work
Entry)
to
the
Connector
(the
conn
entry)
so
that
the
Connector
outputs
these
values.
Notice
that
since
this
Connector
is
set
to
an
output
mode
(AddOnly),
the
Input
Map
tab
is
disabled.
The
attributes
available
for
mapping
are
conveniently
available
in
the
list
marked
Work
Entry,
to
the
left
of
the
Connector
Details
pane.
Chapter
3.
Introducing
IBM
Tivoli
Directory
Integrator
33
Similar
to
what
you
did
on
input
mapping,
drag
the
items
from
the
Work
Entry
list
into
the
one
labeled
Connector
Attribute
(as
before,
you
might
need
to
drop
them
on
the
title
bar).
34
IBM
Tivoli
Directory
Integrator
5.2:
Getting
Started
Guide
Now
you
must
add
the
attribute
that
you
specified
back
on
page
5.
Since
this
attribute
does
not
exist
in
your
input
source,
you
must
compute
its
value.
From
the
Work
Entry
list
you
see
that
you
have
an
attribute
called
FullName
(that
you
computed
using
First
and
Last).
You
can
use
this
value
to
create
an
address
for
each
entry
that
you
process.
Since
it
is
not
uncommon
for
people
to
have
more
than
one
address,
you
can
create
two,
making
a
multi-value
attribute.
To
do
this,
click
the
Add
Attribute
button,
at
left
above
the
Connector
Attribute
list.
This
opens
a
dialog
asking
you
to
name
the
new
attribute.
Call
it
and
click
OK.
Select
the
new
Connector
in
the
list.
Check
the
Advanced
Mapping
checkbox
and
enter
the
following
script:
gn
=
work.getString("First");
cn
=
work.getString("FullName");
These
first
two
lines
store
the
values
of
the
First
and
FullName
attributes
in
local
variables.
Notice
how
you
are
using
the
work
object
to
access
data
inside
the
AssemblyLine:
var
att
=
system.newAttribute("Mail");
Chapter
3.
Introducing
IBM
Tivoli
Directory
Integrator
35
The
next
line
uses
a
system
call
to
create
a
new
attribute.
Give
it
a
temporary
name,
although
good
practice
is
to
name
it
after
the
attribute
you
are
mapping
it
to:
att.addValue(gn
+
"@company.com");
att.addValue(cn.replace("
",".")
+
"@company.com");
These
two
lines
compute
and
add
two
values
to
this
attribute,
making
it
a
multi-value
attribute.
On
the
second
line
you
are
using
the
Java
String
.replace()
function,
since
the
return
value
of
.GetString()
is
a
Java
String
object.
This
call
is
used
to
replace
spaces
with
dots
in
the
name,
so
a
value
like
″Peter
Belamy″
becomes
″Peter.Belamy″.
ret.value
=
att;
Finally,
the
newly
created
attribute
is
returned
and
IBM
Tivoli
Directory
Integrator
converts
the
complex
object
to
the
format
of
the
output
source.
Your
first
data
flow
implementation
is
ready
to
test.
Running
your
AssemblyLine
The
AssemblyLine
is
now
complete
and
ready
to
test.
Click
the
Run
button
in
the
AssemblyLine’s
button
toolbar
at
the
top
of
the
AssemblyLine
Details
window.
When
you
tell
IBM
Tivoli
Directory
Integrator
to
run
an
AssemblyLine,
the
system
starts
an
instance
of
the
server
and
pipes
the
current
configuration
to
it.
Note:
You
can
start
the
server
from
outside
the
Toolkit
IDE
and
instruct
it
to
use
a
specific
Config.
IBM
Tivoli
Directory
Integrator
now
creates
a
new
pane
named
ExecuteTask-AL
showing
you
a
log
of
the
starting
of
your
newly
created
AssemblyLine.
36
IBM
Tivoli
Directory
Integrator
5.2:
Getting
Started
Guide
Aside
from
the
Process
exit
code
line
at
the
bottom
that
simply
tells
you
that
the
server
stopped
after
starting
the
specified
AssemblyLine,
the
output
in
this
window
is
divided
into
three
main
parts:
v
Information
about
the
version
of
the
server
that
you
are
running.
v
Description
of
the
environment
that
IBM
Tivoli
Directory
Integrator
is
running
in,
including
which
VM
it
is
configured
to
use,
and
the
working
directory.
v
Information
about
how
your
solution
started,
including:
–
Which
parameters
were
used
to
start
the
server
–
The
Config
that
is
being
used
(which
in
this
case
is
shown
as
<stdin>
meaning
that
it
was
piped
to
the
runtime
server
from
the
IDE)
–
Messages
generated
during
the
running
of
the
AssemblyLine
and
its
Connectors
You
can
also
send
messages
to
the
log
yourself
using
special
IBM
Tivoli
Directory
Integrator
objects
and
functions
available
when
writing
your
scripts,
such
as
the
task.logmsg(″your
_message_goes_here″)
function.
At
the
bottom
of
this
last
section
is
the
message
that
the
AssemblyLine
(CSVtoXML)
ran
without
errors.
This
means
that
you
can
open
the
output
file
that
you
specified
previously
(see
“Adding
the
Output
Connector”
on
page
31).
Opening
this
file
(for
example,
in
a
browser)
enables
you
to
confirm
that
the
AssemblyLine
has
actually
converted
the
CSV
input
data
to
the
XML
document.
Chapter
3.
Introducing
IBM
Tivoli
Directory
Integrator
37
Even
the
and
FullName
attributes
are
there,
computed
by
your
script
snippets.
38
IBM
Tivoli
Directory
Integrator
5.2:
Getting
Started
Guide
However,
one
of
the
entries
(Roger,
outlined
in
the
previous
screenshot)
is
incomplete.
This
entry
is
lacking
both
the
Last
and
Title
attributes.
If
you
check
the
input
data
file
(see
page
9)
then
you
can
see
that
these
fields
are
actually
missing
from
the
input
CSV
file.
The
easiest
solution
is
to
edit
the
CSV
file
and
add
the
missing
fields.
However,
few
data
sources
give
you
this
much
control.
Instead,
filter
the
input
by
scripting
a
Hook.
Note:
Before
improving
the
AssemblyLine,
do
one
of
the
following
to
save
the
work
first:
v
Click
Savebutton
in
the
main
tool
bar.
v
Select
File–>Save
from
the
Main
Menu.
v
Press
Ctrl+S.
Working
with
Hooks
Hooks
are
waypoints
in
the
running
of
the
AssemblyLine
and
its
Connectors
where
you
can
add
your
own
logic.
While
most
Hooks
are
associated
with
Connectors,
there
are
a
handful
that
appear
in
the
AssemblyLine
Hook
tab.
These
are
fired
at
the
start
and
end
of
your
data
flows
lifecycle:
1.
Prologs
are
started.
a.
If
any
Library
Scripts
are
configured
as
Global
Prologs
for
your
AssemblyLine,
then
they
are
run.
b.
There
are
two
AssemblyLine
Prolog
Hooks:
one
which
is
fired
off
before
Connectors
initialize
connections
to
their
data
sources,
and
one
after.
Since
you
can
control
the
AssemblyLine
and
its
Connectors
from
your
scripts,
you
can
reconfigure
components
and
even
change
the
flow
itself.
c.
Now
Connectors
are
initialized.
d.
After
initialization,
if
the
Hook
called
Prolog
is
enabled
then
it
is
started.2.
Now
the
Data
Flow
begins
and
control
is
handed
over
to
first
Connector.
When
completed,
processing
moves
to
the
next
Connector
in
the
line,
and
so
on
until
the
last
Connector
completes.
If
there
are
Iterators
in
the
AssemblyLine
(for
example,
Connectors
in
Iterator
mode)
then
control
goes
back
to
the
start
and
the
AssemblyLine
repeats
for
the
next
entry.
Although
each
Connector
mode
has
its
built-in
flow,
these
are
consistent
and
share
relevant
Hooks.
For
example,
Lookup,
Update
and
Delete
modes
are
all
wired
in
the
same
way
to
handle
searches
(as
you
can
see
if
you
try
switching
modes
while
viewing
the
Hooks
tab).
There
is
a
graphical
description
of
these
flows
available
in
the
form
of
Connector
Mode
Flow
Diagrams.
These
can
be
found
in
the
IBM
Tivoli
Directory
Integrator
Reference
Guide
and
as
a
separate
quick
reference
guide.
3.
When
all
iterations
are
over
(for
example,
when
the
last
Iterator
reaches
end-of-data),
the
AssemblyLine
Epilog
is
run.
4.
Finally,
Connectors
close
their
connections.
Getting
back
to
your
example,
you
want
to
check
for
missing
data
in
your
CSV
input
file.
Since
this
data
source
is
handled
by
the
Connector
called
InputPeople,
select
it
in
the
Connector
List
and
then
select
the
Hooks
tab
(next
to
Attribute
Map).
This
is
where
you
add
filtering
logic.
Chapter
3.
Introducing
IBM
Tivoli
Directory
Integrator
39
There
are
three
sets
of
Hooks
for
every
Connector,
represented
by
folders
in
the
Hooks
tree-list:
In
Prolog
There
are
at
least
two
Hooks
in
this
folder:
v
One
run
after
the
AssemblyLine
Prolog
(Before
Initialization).
v
One
run
just
before
the
AssemblyLine
Prolog
(After
Initialization).
In
Iterator
mode
you
also
get
additional
Hooks
for
before
and
after
the
selection
operation,
when
the
Connector
gets
a
view
of
the
data
to
iterate
from.
DataFlow
Hooks
that
are
started
at
every
iteration
of
the
AssemblyLine,
each
time
the
Connector
is
run.
Hooks
such
as
Before
Execute
and
Default
Error
are
common
to
all
Connector
modes.
Most
of
the
others
are
mode-specific.
Since
your
InputPeople
Connector
is
in
Iterator
mode,
it
is
doing
a
number
of
GetNext
operations
to
retrieve
the
input
data.
Iterator
mode
gives
you
Hooks
such
as
Before
GetNext
and
After
GetNext
so
that
you
can
wrap
this
read
operation
in
your
own
logic.
After
Epilog
These
Hooks
are
started
once
at
the
end
of
the
AssemblyLine’s
life-cycle,
just
after
the
AssemblyLine’s
Epilog.
Note
that
each
Connector
goes
through
its
Epilog
cycle
(Before
Close,
close
connection,
After
Close)
in
the
same
order
as
they
appear
in
the
AssemblyLine
(do
not
rely
on
this
in
your
Hook
code).
40
IBM
Tivoli
Directory
Integrator
5.2:
Getting
Started
Guide
With
the
InputPeople
Connector
selected,
click
the
After
GetNext
Hook
in
the
list.
Enter
the
following
script
in
the
edit
window
to
the
right
of
the
Hooks
list:
Note:
If
a
pane
is
too
small
(such
as
the
Script
Editor)
then
try
resizing
it
by
clicking
and
dragging
one
or
more
separator
bars.
sn
=
conn.getString("Last");
title
=
conn.getString("Title");
The
first
two
lines
retrieve
and
store
the
values
of
two
attributes
that
are
available
in
the
Raw
Connector.
If
you
remember
from
the
discussion
on
Attribute
Mapping
(page
24)
each
Connector
uses
a
local
storage
object
for
use
with
its
data
operations.
This
object
is
referenced
through
the
script
variable
conn.
In
the
case
of
the
previous
example,
you
can
use
the
GetNext
Successful
or
Default
Success
Hooks
to
do
the
filtering.
Since
these
Hooks
come
after
the
Input
Attribute
Map,
these
attributes
are
mapped
to
the
Work
Entry,
and
you
can
write
your
script
using
the
work
variable
instead.
if
(sn
==
null
||
title
==
null)
{
Check
to
see
if
the
value
returned
for
the
Last
or
the
Title
attribute
is
null
(does
not
exist
in
the
input
data
source).
If
this
is
the
case,
then
the
next
three
lines
are
started.
Chapter
3.
Introducing
IBM
Tivoli
Directory
Integrator
41
Note:
You
might
want
to
test
for
the
existence
of
more
fields
in
a
production
version
of
this
AssemblyLine.task.logmsg("-->
Record
skipped
(missing
data)");
The
task
object
gives
you
access
to
AssemblyLine
functions,
such
as
logmsg()
which
lets
you
write
to
the
AssemblyLine’s
logfile.
task.dumpEntry(conn);
This
time
you
use
the
AssemblyLine’s
(task)
dumpEntry()
function
to
write
the
contents
of
the
Raw
Connector’s
local
storage
object
(conn)
to
the
logfile.
Note:
Conn
and
work
are
the
same
type
of
object,
so
functions
such
as
dumpEntry()
work
equally
well
on
both.
system.skipEntry();
}
Finally,
use
the
system
object’s
skipEntry()
function
to
signal
to
IBM
Tivoli
Directory
Integrator
to
skip
this
input
entry,
start
back
at
the
top
of
the
AssemblyLine
loop
and
read
the
next
one.
Before
testing
the
line
again,
make
a
slight
change
to
the
output
Attribute
Map.
Schema
conversion
In
your
example
(see
page
5),
the
output
attributes
have
the
same
names
as
those
in
the
input
source.
But
imagine
for
a
moment
that
the
specification
calls
for
the
output
attributes
to
be
called
FirstName
and
LastName:
FirstName
=DS1.First
LastName
=DS1.Last
FullName
=DS1.First+"
"+DS1.Last
Title
=DS1.Title
=<compute_from_name>
IBM
Tivoli
Directory
Integrator
makes
mapping
attribute
names
between
schemas
easy,
and
all
you
need
to
do
is
update
the
names
of
these
attributes
directly
in
the
Attribute
Map
of
the
output
Connector.
Select
the
XMLOutput
Connector,
click
on
the
attribute
that
you
want
to
change
in
the
Attribute
Map
and
start
typing.
42
IBM
Tivoli
Directory
Integrator
5.2:
Getting
Started
Guide
Don’t
worry
about
this
affecting
scripts
in
the
AssemblyLine,
these
names
are
being
changed
locally
for
the
Attribute
Mapping
phase
of
the
output
Connector.
The
First
and
Last
attributes
are
still
read
in
correctly,
and
are
available
inside
the
AssemblyLine.
Note:
Because
IBM
Tivoli
Directory
Integrator
keeps
focus
in
the
field
that
you
are
entering
even
if
you
switch
to
a
different
Connector
or
AssemblyLine,
you
can
still
be
in
edit
mode
for
the
attribute
name.
To
leave
edit
mode,
either
click
on
a
different
attribute
in
the
same
map,
or
press
Enter
so
that
IBM
Tivoli
Directory
Integrator
knows
you
are
done.
Leave
these
changes
in
(even
though
this
is
not
part
of
your
original
specification)
and
then
run
the
AssemblyLine
again.
When
IBM
Tivoli
Directory
Integrator
finishes,
go
back
to
the
output
browser
window
and
click
the
Refresh
button.
If
you
closed
that
window
then
you
must
repeat
the
steps
you
used
to
open
the
output
file
after
the
first
run
(see
“Running
your
AssemblyLine”
on
page
36).
When
the
output
file
is
visible
again,
confirm
that
Roger
is
no
longer
there
(he
used
to
be
between
Jill
and
Gregory).
Also,
notice
the
changes
you
made
to
two
of
the
attribute
names.
Save
your
Config
again
(Ctrl+S),
and
go
to
the
next
step,
collecting
data
from
a
third
data
source.
Chapter
3.
Introducing
IBM
Tivoli
Directory
Integrator
43
Adding
the
Join
Connector
Included
with
the
Tutorial
files
is
a
simple
database
of
people
who
owe
money.
Use
this
source
to
send
information
about
the
debtors
into
the
output
XML
document.
The
first
step
is
to
add
a
third
Connector
by
clicking
Add
in
the
AssemblyLine
tool
bar.
Call
this
Connector
Debtors
and
choose
the
BTree
Object
DB
Connector.
This
Connector
needs
to
be
in
Lookup
mode
since
you
are
searching
for
records
that
match
the
data
inside
the
AssemblyLine.
When
you
add
a
Connector
to
the
list,
IBM
Tivoli
Directory
Integrator
drops
the
new
Connector
at
the
end
of
the
AssemblyLine.
But
this
won’t
work,
because
you
need
to
do
the
collection
after
the
input
(iteration),
but
before
your
output
Connector.
To
fix
this,
select
the
Debtors
Connector
and
click
the
Up
button
in
the
AssemblyLine
data
flow
tool
bar.
44
IBM
Tivoli
Directory
Integrator
5.2:
Getting
Started
Guide
This
moves
the
Connector
up
one
slot
so
that
it
is
started
after
InputPeople,
but
before
XMLOutput.
Now
select
the
Config...
tab
in
order
to
set
up
this
Connector.
Chapter
3.
Introducing
IBM
Tivoli
Directory
Integrator
45
Enter
the
pathname
of
the
data
file,
which
might
be
different
from
the
one
above,
depending
on
where
you
installed
IBM
Tivoli
Directory
Integrator
(note
that
the
database
file
itself
is
called
Debtors.dat).
In
the
Key
Attribute
Name
field
you
need
to
specify
the
name
of
the
attribute
that
uniquely
identifies
these
records.
In
the
tutorial
database,
this
is
the
FullName
attribute
(which
gives
you
a
hint
as
to
why
you
constructed
a
similarly
named
attribute
in
the
input
Connector).
When
you
want
to
test
this
Connector,
use
the
Schema
tab
and
click
on
the
Connect
and
Next
buttons
as
you
did
for
InputPeople.
Or,
you
can
go
straight
to
the
Input
Map
tab
and
use
the
handy
Quick
Discovery
button.
46
IBM
Tivoli
Directory
Integrator
5.2:
Getting
Started
Guide
This
causes
the
Connector
to
connect
to
its
source,
do
a
single
GetNext
on
the
data
set
and
examine
the
returned
entry.
The
attributes
found
here
are
displayed
in
the
Available
Connector
Attributes
window
and
are
ready
for
mapping.
Now
although
this
does
not
discover
all
the
attributes
defined
in
the
schema
of
the
data
source
(you
need
to
use
the
Discover
Schema
button
in
the
Schema
tab
for
this)
it
is
enough
for
us
to
continue
your
work.
You
now
proceed
to
set
up
the
Attribute
Map
such
that
the
relevant
information
becomes
available
to
the
AssemblyLine.
Go
to
the
Input
Map
pane
by
clicking
the
tab
(next
to
Schema),
and
then
drag
Amount
and
DateOfLoan
from
the
list
of
Available
Connector
Attributes
into
the
Work
Attribute
box.
Note:
As
you’ll
see
in
the
following
section,
you
use
this
data
source’s
FullName
field
to
set
up
the
search
criteria
for
the
Lookup.
However,
an
attribute
does
not
need
to
be
included
in
the
Attribute
Map
in
order
for
you
to
use
for
searching,
it
just
needs
to
be
available
in
the
data
source.
Setting
up
Link
Criteria
Because
it’s
in
Lookup
mode,
the
new
Debtors
Connector
is
searching
for
specific
entries
in
its
data
source,
trying
to
find
a
match
for
the
entry
that
is
already
inside
the
AssemblyLine.
Exactly
how
this
match
is
made
is
specified
by
you
in
what
is
called
the
Connector’s
Link
Criteria.
Chapter
3.
Introducing
IBM
Tivoli
Directory
Integrator
47
You
might
have
noticed
that
when
you
added
the
Debtors
Connector
(and
made
sure
its
mode
was
Lookup)
a
new
tab
became
available,
Link
Criteria,
next
to
a
tab
named
Output
Map.
Selecting
this
tab
brings
up
the
Link
Criteria
display
where
you
can
specify
how
this
Connector
performs
the
lookup.
Recall
the
IBM
Tivoli
Directory
Integrator
feature
for
scripting
an
Attribute
Map
directly.
The
same
principle
applies
here.
By
checking
the
Build
criteria
with
custom
script
checkbox
(next
to
the
Link
Criteria
toolbar),
you
get
an
Editor
window
where
you
can
write
the
data
source-specific
lookup
call.
This
can
be
an
SQL
SELECT
statement
for
a
JDBC
Connector,
or
an
LDAP
search
call
if
connected
to
a
directory.
However,
just
as
with
Attribute
Mapping,
IBM
Tivoli
Directory
Integrator
can
create
the
relevant
API
call
for
the
underlying
data
source,
keeping
the
solution
more
technology
independent.
Click
the
Add
new
Link
Criteria
button
on
the
Link
Criteria
toolbar,
under
the
Config...
tab:
48
IBM
Tivoli
Directory
Integrator
5.2:
Getting
Started
Guide
When
the
Link
Criteria
dialog
box
appears,
choose
an
attribute
from
the
schema
that
IBM
Tivoli
Directory
Integrator
discovered
in
the
data
source.
Then
select
a
comparison
operation
(for
example,
equals
or
contains).
The
last
field
lets
you
specify
the
attribute
inside
the
AssemblyLine
to
be
compared
to.
Click
OK
when
you
are
done.
Note:
The
dollar
sign
($)
character
in
front
of
the
FullName
attribute
in
the
AssemblyLine
enables
IBM
Tivoli
Directory
Integrator
to
retrieve
the
first
value
of
this
attribute
(it
might
have
any
number
of
values)
to
use
in
building
the
Link
Criteria.
If
you
want
to
match
any
one
of
the
values
of
a
multi-value
attribute,
you
can
use
the
at
symbol
(@)
instead.
When
the
dialog
is
closed
and
you
are
back
at
the
AssemblyLine
screen,
select
the
XMLOutput
Connector
to
update
its
Attribute
Map
to
include
the
new
data
being
collected
into
the
line.
From
the
Work
Entry
box,
drag
the
new
Amount
and
DateOfLoan
attributes
onto
the
Connector
Attribute
box.
Chapter
3.
Introducing
IBM
Tivoli
Directory
Integrator
49
Save
your
work
and
run
the
AssemblyLine
again.
What
happened?
The
AssemblyLine
crashed!
This
is
because
you
have
not
accounted
for
the
situation
where
the
Debtor
Lookup
Connector
fails
to
find
entries
in
its
database,
50
IBM
Tivoli
Directory
Integrator
5.2:
Getting
Started
Guide
keyed
on
the
FullName
attribute.
Fortunately,
IBM
Tivoli
Directory
Integrator
has
a
number
of
ways
to
deal
with
this
situation.
In
this
case,
you
can
program
a
Hook
to
remedy
the
problem.
You
must
make
a
decision
as
to
what
to
do:
v
You
can
choose
to
ignore
the
fact
that
the
entry
sometimes
does
not
exist
in
the
Debtors.dat
database.
In
that
case,
you
instruct
the
program
to
ignore,
and
your
output
contains
all
entries,
some
with
information
about
their
debts,
and
some
without.
v
You
might
want
to
see
people
with
debts
only,
in
which
case
you
instruct
the
system
to
skip
people
with
no
entry
in
the
table,
for
example,
with
no
debt
record.
Either
way,
it
involves
enabling
the
Hook
called
On
No
Match
in
the
Debtors
Connector.
1.
Go
to
this
Connector,
and
click
the
Hooks
tab.
2.
Click
on
the
On
No
Match
Hook
in
the
tree-view
that
is
presented
here.
A
Script
Editor
window
is
displayed.
3.
Check
the
Enabled
checkbox,
save
your
work
and
run
the
AssemblyLine
again.
By
simply
enabling
the
Hook,
you
are
telling
IBM
Tivoli
Directory
Integrator
not
to
do
anything
if
no
matching
data
is
found
during
the
Lookup.
When
you
run
the
AssemblyLine
again
it
does
not
crash,
and
the
log
output
looks
like
this:
Chapter
3.
Introducing
IBM
Tivoli
Directory
Integrator
51
Here
you
can
see
the
messages
and
entry
dump
that
you
coded
into
your
filtering
script
(in
the
After
GetNext
Hook
of
InputPeople),
as
well
as
the
message
that
no
errors
were
encountered
this
time.
Note:
The
order
in
which
the
attributes
for
each
entry
appear
is
not
significant,
and
might
not
be
the
same
on
your
system
as
the
order
appears
in
the
screenshots
in
this
document.
Your
XML
output
file
shows
a
couple
of
important
changes
as
well:
v
The
two
new
Debtors
fields
that
were
included
are
visible
in
the
output.
v
The
number
of
attributes
per
XML
entry
became
variable,
since
the
AssemblyLine
did
not
find
debt
information
for
all
of
them.
When
the
Lookup
Connector
(Debtors)
did
not
find
matching
information
in
the
database,
it
defaulted
to
the
AssemblyLine
error
handler
which
then
just
returned
from
the
Hook
(since
there
was
no
specific
code
to
do
anything).
However,
it
did
clear
the
error
condition
so
that
processing
continued,
albeit
with
some
attributes
missing.
This
might
cause
problems
down
the
line,
but
in
this
situation
it
didn’t.
What
if
you
are
only
interested
in
those
people
that
do
owe
money?
Then
you
need
to
add
this
snippet
of
script
to
the
On
No
Match
Hook
in
the
Debtors
Connector:
system.skipEntry();
52
IBM
Tivoli
Directory
Integrator
5.2:
Getting
Started
Guide
Remember
how
Roger
was
filtered
out
during
the
initial
input.
This
can
cause
a
situation
where
the
people
filtered
during
input
actually
owe
money,
but
the
AssemblyLine
never
gets
that
far
with
these
records.
As
an
alternative,
you
can
create
default
values
for
missing
attributes
in
the
first
Connector.
IBM
Tivoli
Directory
Integrator
provides
numerous
ways
to
handle
missing
values.
Now
that
you’ve
taken
a
look
at
how
you
describe
the
systems
and
data
flows
that
make
up
your
integration
solution,
it’s
time
to
look
at
how
IBM
Tivoli
Directory
Integrator
enables
you
to
detect
and
dispatch
change
events
in
your
infrastructure.
EventHandlers
The
third
and
last
type
of
component
in
IBM
Tivoli
Directory
Integrator
is
the
EventHandler.
As
the
name
implies,
this
component
enables
us
to
create
real-time,
event-driven
integration
solutions.
EventHandlers
enable
us
to
plug
into
systems
and
services
and
then
wait
for
some
sort
of
event-notification.
Examples
include
arriving
in
a
POP3/IMAP
mailbox,
a
file
appearing
in
an
FTP
URL
and
changes
made
in
a
directory.
EventHandlers
can
be
configured
to
perform
any
number
of
actions
based
on
the
type
of
event
intercepted:
v
Passing
incoming
data
through
one
or
more
parsers
Chapter
3.
Introducing
IBM
Tivoli
Directory
Integrator
53
v
Starting
AssemblyLines
with
event
parameters
that
they
need
to
do
their
work
v
Invoking
external
programs
or
libraries
In
short,
whatever
you
need
them
to
do
in
order
to
interpret
and
dispatch
the
event.
As
with
the
other
components,
most
EventHandlers
work
in
a
similar
fashion.
However,
some
are
implemented
completely
with
script
(such
as
the
Generic
Thread
EventHandler)
or
need
a
specialized
interface
for
configuration
(for
example,
the
Web
Services
EventHandler).
For
the
sake
of
simplicity,
you
are
looking
at
the
standard
type
of
EventHandler
for
your
example.
When
an
EventHandler
catches
an
event,
it
converts
event
parameters
into
Java
objects
and
stores
them
in
a
local
storage
object.
This
storage
object
is
just
like
the
work
and
conn
objects
that
you
used
in
the
previous
section.
In
the
case
of
EventHandlers,
this
Java
bucket
is
called
event.
In
addition
to
these
event
parameters,
you
sometimes
get
attributes
from
the
event
as
well,
such
as
in
the
case
of
a
modify
event
from
an
LDAP
directory.
In
order
to
keep
data
content
and
parameters
from
getting
mixed
up,
all
these
storage
objects
(including
work
and
conn)
maintain
data
values
in
attributes,
and
parameters
in
something
called
properties.
Properties
are
data
value
carriers
just
like
attributes,
except
that
they
are
always
single-valued
and
are
generally
strings.
When
you
dump
out
an
entry
object
to
the
log
(for
example,
using
the
task.dumpEntry()
function)
you
see
a
separate
section
for
display
of
attributes
and
properties
in
the
log
output.
You
define
how
an
EventHandler
reacts
to
different
events
by
creating
a
set
of
condition-action
rules
based
on
the
values
of
properties
and
attributes
that
are
received
from
the
connected
system.
EventHandlers
are
typically
used
to
dispatch
control
to
one
or
more
AssemblyLines
which
propagate
the
events.
However,
since
EventHandlers
are
scriptable
and
provide
a
good
deal
of
built-in
functionality,
they
can
perform
a
lot
of
work
on
their
own
as
well.
One
of
the
easiest
EventHandlers
to
get
started
with
is
the
HTTP
EventHandler,
so
use
this
component
to
create
a
simple
Web
server.
You
must
create
two
new
files
in
the
examples/Tutorial
directory:
index.html
and
OtherPage.html.
See
Appendix
A,
“index.html
and
OtherPage.html,”
on
page
69
for
the
content
of
these
files.
Open
index.html
in
a
browser.
54
IBM
Tivoli
Directory
Integrator
5.2:
Getting
Started
Guide
This
is
your
main
Web
page
and
it
contains
a
couple
of
links.
The
top
link
references
a
second
Web
page
(OtherPage.html)
while
the
bottom
link
contains
a
reference
to
StartAL.
This
last
link
is
used
to
launch
the
AssemblyLine
that
you
just
built.
The
first
step
is
to
create
an
HTTP
EventHandler
and
configure
it
to
act
as
a
Web
server.
Add
the
new
EventHandler
to
your
Config
now
by
either
using
the
Object–>New
EventHandler
menu
selection,
or
right-click
on
the
EventHandler
folder
in
the
Config
Browser
and
selecting
New
EventHandler
...
from
the
context
menu.
Call
this
new
EventHandler
WebServer.
Chapter
3.
Introducing
IBM
Tivoli
Directory
Integrator
55
IBM
Tivoli
Directory
Integrator
displays
the
EventHandler
details
screen.
Just
as
you
saw
in
the
AssemblyLine
Details
pane,
the
EventHandler
also
provides
you
with
a
set
of
tabs:
Hooks
EventHandlers
have
a
set
of
Hooks
similar
to
those
found
in
an
AssemblyLine:
v
Prolog
v
Epilog
v
Shutdown
Request
Please
note
that
the
Prolog
and
Epilog
Hooks
of
an
EventHandler
are
started
every
time
an
event
is
detected.
Action
Map
The
Action
Map
is
where
you
define
your
condition-action
rules.
56
IBM
Tivoli
Directory
Integrator
5.2:
Getting
Started
Guide
Config
Since
many
EventHandlers
subscribe
to
event
notifications
from
systems
or
devices,
you
need
to
configure
connection
parameters.
Start
by
selecting
the
Config
tab
and
setting
up
your
HTTP
EventHandler.
This
tab
enables
us
to
change
the
EventHandler
type,
select
the
script
language
to
use
and
set
the
various
connection
parameters.
Configure
the
EventHandler
to
listen
to
port
88
on
your
machine
by
entering
this
port
number
in
the
HTTP
Port
parameter.
With
the
Headers
as
Properties
checkbox
selected,
you
are
instructing
the
EventHandler
to
store
all
TCP
and
HTTP
header
values
as
Properties
in
the
event
object.
Now
it’s
time
to
look
at
the
Action
Map
tab.
Chapter
3.
Introducing
IBM
Tivoli
Directory
Integrator
57
This
screen
is
divided
into
three
panes:
Action
Map,
Conditions
and
Action
Items,
each
with
a
row
of
buttons
for
creating,
deleting
and
changing
the
order
of
items
in
the
related
list.
Whenever
an
event
occurs,
the
EventHandler
performs
as
follows:
1.
The
Prolog
Hook
is
run.
2.
Control
is
passed
to
the
first
enabled
Action
Map
item
and
its
Conditions
are
evaluated.
3.
If
the
Conditions
evaluate
to
True
(or
if
there
are
no
Conditions
defined
for
this
Action
Map
item),
then
the
Actions
in
the
Condition
True
tab
are
started.
If
they
evaluate
to
False
then
the
Condition
False
Actions
are
performed.
Errors
are
handled
in
the
On
Error
tab.
4.
When
Actions
have
completed,
control
moves
to
the
next
Action
Map
item
and
step
3
is
repeated
for
this
item.
However,
if
the
Consume
checkbox
is
selected
for
this
Action
Map
item,
and
if
even
a
single
Action
is
performed,
then
processing
stops
for
this
event
and
control
is
passed
to
the
next
step
(the
Epilog).
5.
The
Epilog
Hook
is
started.
6.
The
EventHandler
waits
for
the
next
event.
Create
a
new
Action
Map
item
by
pressing
the
Add
new
Action
Map
item
button
and
calling
this
new
item
DumpEventToLog.
58
IBM
Tivoli
Directory
Integrator
5.2:
Getting
Started
Guide
Do
not
create
any
Conditions
for
this
Action
Map
item.
This
means
that
the
EventHandler
always
starts
the
Actions
defined
in
the
Condition
True
tab.
Select
the
new
Action
Map
item,
then
the
Condition
True
tab
and
add
a
new
Action.
Chapter
3.
Introducing
IBM
Tivoli
Directory
Integrator
59
As
you
can
see
from
the
Action
selection
dialog
box
in
this
screenshot,
you
have
a
number
of
standard
actions
to
choose
from:
v
Invoking
one
or
more
Parsers
v
Writing
your
own
custom
script
v
Adding
and
removing
event
Properties
and
Attributes
v
Running
an
AssemblyLine
v
Stopping
the
EventHandler
Select
the
Dump
Event
Object
Action
and
press
OK.
Now
you
are
ready
to
test
the
EventHandler
by
clicking
the
Run
button.
When
the
EventHandler
has
started
on
port
88,
open
a
browser
window
and
enter
the
following
URL
into
the
address
field:
http://localhost:88
Nothing
is
displayed
in
your
browser,
but
if
you
bring
up
IBM
Tivoli
Directory
Integrator
again
you
see
that
the
event
was
caught
by
the
EventHandler
and
the
various
event
parameters
have
been
dumped
to
log,
just
as
IBM
Tivoli
Directory
Integrator
was
instructed
to
do.
60
IBM
Tivoli
Directory
Integrator
5.2:
Getting
Started
Guide
Dumping
out
the
contents
of
the
event
object
is
a
fast
and
visual
way
of
identifying
the
parameters
returned
with
the
event,
and
that
are
available
for
you
to
use
in
defining
Conditions.
Use
the
http.base
Property
that
is
highlighted
in
the
previous
screenshot
to
try
this.
Note
that
before
the
changes
you
are
about
to
make
to
the
EventHandler
take
effect,
you
must
stop
the
currently
running
instance
by
clicking
the
red
Stop
button,
or
by
closing
the
Execute
pane.
Go
back
to
your
EventHandler,
create
a
new
Action
Map
item
and
call
it
StartAL.
Select
this
new
Action
Map
item
and
click
the
Add
new
Condition
button.
Chapter
3.
Introducing
IBM
Tivoli
Directory
Integrator
61
As
usual,
IBM
Tivoli
Directory
Integrator
enables
us
to
handle
complex
situations
with
custom
script.
You
don’t
need
this
flexibility
here,
so
select
Simple
Condition.
The
system
then
presents
us
with
a
Condition
dialog.
62
IBM
Tivoli
Directory
Integrator
5.2:
Getting
Started
Guide
Enter
http.base
in
the
Attribute/Property
Name
field
and
then
select
the
contains
operator
from
the
drop-down
list.
In
the
Value
field,
enter
the
quoted
text
″StartAL″.
This
instructs
the
EventHandler
to
check
the
http.base
Property
to
see
if
it
contains
the
text
″StartAL″.
Since
you
did
not
select
the
Case
Sensitive
checkbox,
case
does
not
affect
the
result
of
this
Condition.
Now
all
you
have
to
do
is
tell
the
EventHandler
what
to
do
when
your
Condition
is
met.
With
the
StartAL
Action
Map
item
still
selected,
add
a
new
Action
to
the
Condition
True
folder
tab
and
select
the
Run
AssemblyLine
Action.
Chapter
3.
Introducing
IBM
Tivoli
Directory
Integrator
63
You
can
double-click
any
Action
in
order
to
get
the
Action
details
dialog:
Use
the
drop-down
list
to
select
your
CSVtoXML
AssemblyLine
and
then
click
the
checkbox
labeled
Wait
for
completion.
Selecting
this
option
tells
the
EventHandler
to
pause
until
your
AssemblyLine
is
finished,
preventing
us
from
launching
it
multiple
times
in
parallel
by
accident.
When
you
have
entered
the
details
for
this
Action,
close
the
dialog
using
the
Close
pane
button
(see
outline
in
previous
screenshot).
64
IBM
Tivoli
Directory
Integrator
5.2:
Getting
Started
Guide
Start
the
EventHandler
again.
Wait
for
it
to
start
and
then
open
your
browser
window.
You
want
to
access
the
same
machine
and
port
number
(http://localhost:88)
but
this
time
append
your
Condition
text
(startAL)
to
the
end
of
the
URL:
http://localhost:88/startAL
You
might
notice
that
your
browser
took
a
moment
to
return.
This
was
the
EventHandler
launching
your
AssemblyLine
and
then
waiting
for
it
to
complete.
If
you
switch
back
to
IBM
Tivoli
Directory
Integrator
you
can
see
in
the
log
output
that
after
the
EventHandler
dumped
out
the
event
object
it
ran
your
AssemblyLine.
So
far
so
good,
but
your
EventHandler
is
still
not
working
like
a
Web
server
yet.
To
add
this
functionality
you
must
add
some
additional
code
to
the
Condition
False
tab
of
your
StartAL
Action
Map
item.
With
that
item
selected,
add
a
Custom
Script
Action
to
the
Condition
False
tab
(double-click
the
new
Action
to
get
the
details
screen).
You
might
want
to
drag
the
divider
bar
between
Conditions
and
Actions
upwards
to
give
you
more
room
to
write
your
script.
Chapter
3.
Introducing
IBM
Tivoli
Directory
Integrator
65
Now
enter
the
following
script
in
the
Script
Editor
window
for
this
Action:
//
First
we
get
the
http.base
property
(returned
as
a
Java
String
object).
//
The
second
line
below
defines
a
new
variable
with
the
full
path
to
//
where
the
Tutorial
HTML
files
are
located
on
your
machine.
//
base
=
event.getProperty("http.base");
path
=
"C:/Program
Files/IBM/IBMDirectoryIntegrator/examples/Tutorial/";
//
We
can
use
the
Java
String
endsWith()
function
to
check
the
extension
//
of
the
file
being
requested
by
the
browser.
We
then
set
the
properties
//
for
the
HTTP
message
that
the
EventHandler
will
pass
back
to
the
browser.
if
(
base.endsWith(".gif")
)
event.setProperty
("http.content-type",
"image/gif")
else
if
(
base.endsWith(".jpg")
||
base.endsWith(".jpeg")
)
event.setProperty
("http.content-type",
"image/jpeg")
else
event.setProperty
("http.content-type",
"text/html");
//
If
this
is
a
root
or
null
request,
add
the
name
of
our
main
Web
//
page
("index.html").
if
(
base
==
"/"
)
base
=
"/"
+
"index.html";
//
Now
we
create
a
new
Java
file
object
with
the
name
of
file
//
that
was
requested,
and
prepended
with
the
path
variable
that
//
we
created
above.
var
file
=
new
java.io.File(path
+
base);
//
Here
we
write
the
name
of
the
file
to
the
log.
66
IBM
Tivoli
Directory
Integrator
5.2:
Getting
Started
Guide
task.logmsg
("File
request:
"
+
file
);
//
Finally,
we
can
use
the
exists()
function
to
see
if
the
file
was
found.
//
If
so,
we
pass
it
back
in
the
http.body
property.
If
not,
we
set
the
//
status
so
that
the
browser
will
display
the
standard
404
error.
if
(
file.exists()
)
event.setProperty
("http.body",
file);
else
event.setProperty
("http.status",
"NOT
FOUND");
This
is
the
longest
snippet
yet.
Even
so,
this
is
still
not
much
code
considering
that
you
have
now
built
a
Web
server.
Start
the
EventHandler
again
and
type
in
http://localhost:88
in
your
browser.
You
get
the
Web
page
that
you
looked
at
earlier.
In
fact,
the
EventHandler
had
to
service
two
events:
first
it
returned
the
index.html
page,
and
then
when
your
browser
started
rendering
the
HTML
it
detected
a
GIF
image
and
requested
this
from
the
server
as
well.
If
you
look
in
the
log
output
you
can
see
this
additional
event.
Try
clicking
through
to
the
other
page
and
then
back
again.
Your
simple
Web
server
services
all
available
pages.
If
you
enter
the
URL
of
a
file
that
does
not
exist
(for
example,
http://localhost:88/BadPage.html),
the
EventHandler
returns
a
File
Not
Found
error
in
the
browser.
At
the
bottom
of
the
main
page
is
the
second
link
you
looked
at
earlier.
If
you
hover
your
mouse
over
it,
you
see
that
it
references
the
URL
http://localhost:/StartAL.
When
you
click
on
this
link,
your
previously
defined
Condition
is
matched
and
the
AssemblyLine
started.
Congratulations!
You’ve
completed
your
basic
training
with
IBM
Tivoli
Directory
Integrator
and
can
start
looking
at
building
your
own
solutions.
Of
course,
the
road
does
not
stop
here
and
there
is
a
wealth
of
functionality
to
discover
and
explore.
As
with
all
development
tools,
expertise
comes
with
experience,
so
get
cracking.
Final
thoughts
Although
IBM
Tivoli
Directory
Integrator
makes
building
data
flows
fast
and
easy,
the
quality
of
the
resulting
solution
is
dependent
on
how
good
your
specification
is.
IBM
Tivoli
Directory
Integrator
actually
helps
by
removing
the
platform
and
vendor
technology
blinders
that
block
your
vision
and
limit
your
imagination.
Chapter
3.
Introducing
IBM
Tivoli
Directory
Integrator
67
When
you
approach
an
integration
problem
at
the
data
flow
level,
you
reduce
complexity.
This
gives
you
gains
across
the
board:
in
deployment
speed,
accuracy
of
the
solution,
robustness,
maintainability,
and
so
forth.
In
fact,
as
you
start
to
think
in
terms
of
the
simplify
and
solve
mantra,
you
see
your
installation
and
its
integration
possibilities
from
a
whole
new
perspective.
IBM
Tivoli
Directory
Integrator
continues
making
a
difference
long
after
your
solution
is
completed
and
deployed.
As
your
business
and
technical
requirements
change,
IBM
Tivoli
Directory
Integrator
lets
you
enhance
and
grow
your
solution
to
meet
these
new
challenges.
That’s
the
beauty
of
IBM
Tivoli
Directory
Integrator:
incremental
implementation.
You
can
grow
your
integration
solution
(and
your
infrastructure)
to
fit
your
needs,
as
well
as
the
environment
where
it
lives.
Perception
is
reality,
and
your
perception
is
formed
(and
limited)
by
the
toolset
you
use.
The
choice
is
simple.
You
can
continue
to
accept
reality
as
you
perceive
it,
whittling
away
at
the
vision
of
your
integration
infrastructure
in
order
to
make
it
fit
the
tools
you
are
using,
or
you
can
switch
tools.
68
IBM
Tivoli
Directory
Integrator
5.2:
Getting
Started
Guide
Appendix
A.
index.html
and
OtherPage.html
You
must
create
two
new
files
in
order
to
complete
the
examples
in
this
manual:
index.html
and
OtherPage.html.
You
must
create
these
files
in
the
examples/Tutorial
directory.
index.html
The
following
is
the
content
of
the
index.html
file.
Copy
and
paste
this
code
into
a
flat
editor,
for
example,
Notepad,
and
save
the
file
as
index.html:
<html>
<head>
<title>IBM
Tivoli
Directory
Integrator</title>
</head>
<body>
<h1>This
sample
website
is
powered
by
<br>IBM
Tivoli
Directory
Integrator</h1>
<br>
<br>
<br>
<br>
Click
<a
href="OtherPage.html">here</a>
to
go
to
the
other
page.
<br>
<br>
<br>
<br>
Click
<a
href="StartAL">here</a>
to
run
our
<i>Tutorial1</i>
AssemblyLine.
</body>
</html>
OtherPage.html
The
following
is
the
content
of
the
OtherPage.html
file.
Copy
and
paste
this
code
into
a
flat
editor,
for
example,
Notepad,
and
save
the
file
as
OtherPage.html:
<html>
<head>
<title>IBM
Tivoli
Directory
Integrator
-
Page
2</title>
</head>
<body>
<h1>...and
this
is
the
other
page.</h1>
</div>
<br>
<br>
<br>
<br>
<br>
<br>
Click
<a
href="index.html">here</a>
to
go
to
back
to
the
main
page.
</body>
</html>
©
Copyright
IBM
Corp.
2002,
2003
69
70
IBM
Tivoli
Directory
Integrator
5.2:
Getting
Started
Guide
Appendix
B.
Notices
This
information
was
developed
for
products
and
services
offered
in
the
U.S.A.
IBM
might
not
offer
the
products,
services,
or
features
discussed
in
this
document
in
other
countries.
Consult
your
local
IBM
representative
for
information
on
the
products
and
services
currently
available
in
your
area.
Any
reference
to
an
IBM
product,
program,
or
service
is
not
intended
to
state
or
imply
that
only
that
IBM
product,
program,
or
service
may
be
used.
Any
functionally
equivalent
product,
program,
or
service
that
does
not
infringe
any
IBM
intellectual
property
right
may
be
used
instead.
However,
it
is
the
user’s
responsibility
to
evaluate
and
verify
the
operation
of
any
non-IBM
product,
program,
or
service.
IBM
may
have
patents
or
pending
patent
applications
covering
subject
matter
in
this
document.
The
furnishing
of
this
document
does
not
give
you
any
license
to
these
patents.
You
can
send
license
inquiries,
in
writing,
to:
IBM
Director
of
Licensing
IBM
Corporation
North
Castle
Drive
Armonk,
NY
10504-1785
U.S.A.
For
license
inquiries
regarding
double-byte
(DBCS)
information,
contact
the
IBM
Intellectual
Property
Department
in
your
country
or
send
inquiries,
in
writing,
to:
IBM
World
Trade
Asia
Corporation
Licensing
2-31
Roppongi
3-chome,
Minato-ku
Tokyo
106,
Japan
The
following
paragraph
does
not
apply
to
the
United
Kingdom
or
any
other
country
where
such
provisions
are
inconsistent
with
local
law:
INTERNATIONAL
BUSINESS
MACHINES
CORPORATION
PROVIDES
THIS
PUBLICATION
“AS
IS”
WITHOUT
WARRANTY
OF
ANY
KIND,
EITHER
EXPRESS
OR
IMPLIED,
INCLUDING,
BUT
NOT
LIMITED
TO,
THE
IMPLIED
WARRANTIES
OF
NON-INFRINGEMENT,
MERCHANTABILITY
OR
FITNESS
FOR
A
PARTICULAR
PURPOSE.
Some
states
do
not
allow
disclaimer
of
express
or
implied
warranties
in
certain
transactions,
therefore,
this
statement
may
not
apply
to
you.
This
information
could
include
technical
inaccuracies
or
typographical
errors.
Changes
are
periodically
made
to
the
information
herein;
these
changes
will
be
incorporated
in
new
editions
of
the
information.
IBM
may
make
improvements
and/or
changes
in
the
product(s)
and/or
the
program(s)
described
in
this
information
at
any
time
without
notice.
Any
references
in
this
information
to
non-IBM
Web
sites
are
provided
for
convenience
only
and
do
not
in
any
manner
serve
as
an
endorsement
of
those
Web
sites.
The
materials
at
those
Web
sites
are
not
part
of
the
materials
for
this
IBM
product
and
use
of
those
Web
sites
is
at
your
own
risk.
IBM
may
use
or
distribute
any
of
the
information
you
supply
in
any
way
it
believes
appropriate
without
incurring
any
obligation
to
you.
©
Copyright
IBM
Corp.
2002,
2003
71
Licensees
of
this
program
who
wish
to
have
information
about
it
for
the
purpose
of
enabling:
(i)
the
exchange
of
information
between
independently
created
programs
and
other
programs
(including
this
one)
and
(ii)
the
mutual
use
of
the
information
which
has
been
exchanged,
should
contact:
IBM
Corporation
Department
MU5A46
11301
Burnet
Road
Austin,
TX
78758
U.S.A.
Such
information
may
be
available,
subject
to
appropriate
terms
and
conditions,
including
in
some
cases,
payment
of
a
fee.
The
licensed
program
described
in
this
document
and
all
licensed
material
available
for
it
are
provided
by
IBM
under
terms
of
the
IBM
Customer
Agreement,
IBM
International
Program
License
Agreement,
or
any
equivalent
agreement
between
us.
Any
performance
data
contained
herein
was
determined
in
a
controlled
environment.
Therefore,
the
results
obtained
in
other
operating
environments
may
vary
significantly.
Some
measurements
may
have
been
made
on
development-level
systems
and
there
is
no
guarantee
that
these
measurements
will
be
the
same
on
generally
available
systems.
Furthermore,
some
measurement
may
have
been
estimated
through
extrapolation.
Actual
results
may
vary.
Users
of
this
document
should
verify
the
applicable
data
for
their
specific
environment.
Information
concerning
non-IBM
products
was
obtained
from
the
suppliers
of
those
products,
their
published
announcements
or
other
publicly
available
sources.
IBM
has
not
tested
those
products
and
cannot
confirm
the
accuracy
of
performance,
compatibility
or
any
other
claims
related
to
non-IBM
products.
Questions
on
the
capabilities
of
non-IBM
products
should
be
addressed
to
the
suppliers
of
those
products.
This
information
contains
examples
of
data
and
reports
used
in
daily
business
operations.
To
illustrate
them
as
completely
as
possible,
the
examples
include
the
names
of
individuals,
companies,
brands,
and
products.
All
of
these
names
are
fictitious
and
any
similarity
to
the
names
and
addresses
used
by
an
actual
business
enterprise
is
entirely
coincidental.
COPYRIGHT
LICENSE:
This
information
contains
sample
application
programs
in
source
language,
which
illustrate
programming
techniques
on
various
operating
platforms.
You
may
copy,
modify,
and
distribute
these
sample
programs
in
any
form
without
payment
to
IBM,
for
the
purposes
of
developing,
using,
marketing
or
distributing
application
programs
conforming
to
the
application
programming
interface
for
the
operating
platform
for
which
the
sample
programs
are
written.
These
examples
have
not
been
thoroughly
tested
under
all
conditions.
IBM,
therefore,
cannot
guarantee
or
imply
reliability,
serviceability,
or
function
of
these
programs.
You
may
copy,
modify,
and
distribute
these
sample
programs
in
any
form
without
payment
to
IBM
for
the
purposes
of
developing,
using,
marketing,
or
distributing
application
programs
conforming
to
IBM’s
application
programming
interfaces.
Each
copy
or
any
portion
of
these
sample
programs
or
any
derivative
work,
must
include
a
copyright
notice
as
follows:
72
IBM
Tivoli
Directory
Integrator
5.2:
Getting
Started
Guide
©
(your
company
name)
(year).
Portions
of
this
code
are
derived
from
IBM
Corp.
Sample
Programs.
©
Copyright
IBM
Corp.
_enter
the
year
or
years_.
All
rights
reserved.
If
you
are
viewing
this
information
softcopy,
the
photographs
and
color
illustrations
may
not
appear.
Third-party
component
statements
Apache
statement
This
product
includes
software
developed
by
the
Apache
Software
Foundation
(http://www.apache.org/).
The
Apache
components
include
the
Xerces,
Xalan,
XML4J,
and
Log4J
libraries,
and
these
are
provided
in
object
code
form.
This
object
code
was
obtained
from
the
Apache
web
site
and
is
unmodified.
Apache
license
The
Apache
Software
License,
Version
1.1
Copyright
(c)
1999-2002
The
Apache
Software
Foundation.
All
rights
reserved.
Redistribution
and
use
in
source
and
binary
forms,
with
or
without
modification,
are
permitted
provided
that
the
following
conditions
are
met:
1.
Redistributions
of
source
code
must
retain
the
above
copyright
notice,
this
list
of
conditions
and
the
following
disclaimer.
2.
Redistributions
in
binary
form
must
reproduce
the
above
copyright
notice,
this
list
of
conditions
and
the
following
disclaimer
in
the
documentation
and/or
other
materials
provided
with
the
distribution.
3.
The
end-user
documentation
included
with
the
redistribution,
if
any,
must
include
the
following
acknowledgment:
″This
product
includes
software
developed
by
the
Apache
Software
Foundation
(http://www.apache.org/).″
Alternately,
this
acknowledgment
may
appear
in
the
software
itself,
if
and
wherever
such
third-party
acknowledgments
normally
appear.
4.
The
names
″Xerces″,
″Xalan″,
″log4j″,
″mx4j″
and
″Apache
Software
Foundation″
must
not
be
used
to
endorse
or
promote
products
derived
from
this
software
without
prior
written
permission.
For
written
permission,
please
contact
5.
Products
derived
from
this
software
may
not
be
called
″Apache″,
nor
may
″Apache″
appear
in
their
name,
without
prior
written
permission
of
the
Apache
Software
Foundation.
THIS
SOFTWARE
IS
PROVIDED
″AS
IS″
AND
ANY
EXPRESSED
OR
IMPLIED
WARRANTIES,
INCLUDING,
BUT
NOT
LIMITED
TO,
THE
IMPLIED
WARRANTIES
OF
MERCHANTABILITY
AND
FITNESS
FOR
A
PARTICULAR
PURPOSE
ARE
DISCLAIMED.
IN
NO
EVENT
SHALL
THE
APACHE
SOFTWARE
FOUNDATION
OR
ITS
CONTRIBUTORS
BE
LIABLE
FOR
ANY
DIRECT,
INDIRECT,
INCIDENTAL,
SPECIAL,
EXEMPLARY,
OR
CONSEQUENTIAL
DAMAGES
(INCLUDING,
BUT
NOT
LIMITED
TO,
PROCUREMENT
OF
SUBSTITUTE
GOODS
OR
SERVICES;
LOSS
OF
USE,
DATA,
OR
PROFITS;
OR
BUSINESS
INTERRUPTION)
HOWEVER
CAUSED
AND
ON
ANY
THEORY
OF
LIABILITY,
WHETHER
IN
CONTRACT,
STRICT
LIABILITY,
OR
TORT
(INCLUDING
NEGLIGENCE
OR
OTHERWISE)
ARISING
IN
ANY
WAY
OUT
OF
THE
USE
OF
THIS
SOFTWARE,
EVEN
IF
ADVISED
OF
THE
POSSIBILITY
OF
SUCH
DAMAGE.
Appendix
B.
Notices
73
This
software
consists
of
voluntary
contributions
made
by
many
individuals
on
behalf
of
the
Apache
Software
Foundation.
For
more
information
on
the
Apache
Software
Foundation,
please
see
http://www.apache.org
Rhino
statement
The
IBM
Tivoli
Directory
Integrator
uses
Rhino
(JavaScript
for
Java)
object
code.
The
source
code
for
Rhino
is
located
at
http://www.mozilla.org/rhino/download.html
and
is
available
under
the
terms
of
the
Netscape
Public
License
1.1
(http://www.mozilla.org/MPL/NPL-1.1.html).
The
Rhino
source
code
found
on
the
mozilla
Web
site
was
not
modified
in
generating
the
object
code
used
in
IBM
Tivoli
Directory
Integrator.
Trademarks
The
following
terms
are
trademarks
of
International
Business
Machines
Corporation
in
the
United
States,
or
other
countries,
or
both:
IBM
DB2
Notes
Lotus
Domino
Tivoli
Java,
JavaScript
and
all
Java-based
trademarks
and
logos
are
trademarks
or
registered
trademarks
of
Sun
Microsystems,
Inc.
in
the
United
States
and
other
countries.
Microsoft
and
Windows
are
registered
trademarks
of
Microsoft
Corporation.
UNIX
is
a
registered
trademark
of
The
Open
Group
in
the
United
States
and
other
countries.
Other
company,
product,
and
service
names
may
be
trademarks
or
service
marks
of
others.
74
IBM
Tivoli
Directory
Integrator
5.2:
Getting
Started
Guide
����
Printed
in
USA
SC32-1382-00