IBM E02HMLL-I Implementation Guide - Page 25

Binding, between, elements, trigger

Page 25 highlights

Binding between elements To perform a business process, a collaboration can communicate with connectors, with other collaborations, and with external processes from which it receives access requests through the Server Access Interface. Binding is used to set up communications between the collaboration and these elements when the collaboration is configured. This section describes the concepts for binding. The tools and procedures for creating the bindings are described later in this guide underChapter 9, "Configuring collaboration objects," on page 155). Binding a trigger A collaboration begins a processing flow when it is triggered to do so by the arrival of a business object. The trigger can be any of the following: v A business object from an event published by a connector in a publish-and-subscribe interaction v An access request received through the Server Access Interface v A service call from a connector To allow a collaboration's business processes to be triggered, you must bind the collaboration at configuration time to an element that will supply the triggering event or call. Binding is done between the collaboration and any element that will participate in that collaboration's business process, but only one element can be bound as the trigger. Binding for events When you configure a collaboration at your site to be triggered by events, you bind it to a connector capable of publishing the triggering event. For example, you might specify that the collaboration's Employee.Delete event comes from the PeopleSoft connector. To look more closely at this relationship, recall that the connector actually consists of a connector controller (which, like the collaboration, resides in the InterChange Server Express) and a connector agent (which includes the client connector framework and an application-specific component, and is separate from the InterChange Server Express). The connector controller maintains the binding information and provides its connector agent with a list of events to which collaborations have subscribed. When relevant application operations occur, the connector agent publishes the events on that list to the connector controller. The connector agent sends an event to the connector controller without knowing anything about its ultimate destination at a collaboration. The connector controller is therefore an intermediary between the connector agent and the collaboration, as Figure 8 on page 14 illustrates. Chapter 1. Overview of IBM WebSphere Business Integration Server Express 13

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75
  • 76
  • 77
  • 78
  • 79
  • 80
  • 81
  • 82
  • 83
  • 84
  • 85
  • 86
  • 87
  • 88
  • 89
  • 90
  • 91
  • 92
  • 93
  • 94
  • 95
  • 96
  • 97
  • 98
  • 99
  • 100
  • 101
  • 102
  • 103
  • 104
  • 105
  • 106
  • 107
  • 108
  • 109
  • 110
  • 111
  • 112
  • 113
  • 114
  • 115
  • 116
  • 117
  • 118
  • 119
  • 120
  • 121
  • 122
  • 123
  • 124
  • 125
  • 126
  • 127
  • 128
  • 129
  • 130
  • 131
  • 132
  • 133
  • 134
  • 135
  • 136
  • 137
  • 138
  • 139
  • 140
  • 141
  • 142
  • 143
  • 144
  • 145
  • 146
  • 147
  • 148
  • 149
  • 150
  • 151
  • 152
  • 153
  • 154
  • 155
  • 156
  • 157
  • 158
  • 159
  • 160
  • 161
  • 162
  • 163
  • 164
  • 165
  • 166
  • 167
  • 168
  • 169
  • 170
  • 171
  • 172
  • 173
  • 174
  • 175
  • 176
  • 177
  • 178
  • 179
  • 180
  • 181
  • 182
  • 183
  • 184
  • 185
  • 186
  • 187
  • 188
  • 189
  • 190
  • 191
  • 192
  • 193
  • 194
  • 195
  • 196
  • 197
  • 198
  • 199
  • 200
  • 201
  • 202
  • 203
  • 204
  • 205
  • 206
  • 207
  • 208
  • 209
  • 210
  • 211
  • 212
  • 213
  • 214
  • 215
  • 216
  • 217
  • 218
  • 219
  • 220
  • 221
  • 222
  • 223
  • 224
  • 225
  • 226
  • 227
  • 228
  • 229
  • 230
  • 231
  • 232
  • 233
  • 234
  • 235
  • 236
  • 237
  • 238
  • 239
  • 240
  • 241
  • 242
  • 243
  • 244
  • 245
  • 246
  • 247
  • 248
  • 249
  • 250
  • 251
  • 252
  • 253
  • 254
  • 255
  • 256
  • 257
  • 258
  • 259
  • 260
  • 261
  • 262
  • 263
  • 264
  • 265
  • 266
  • 267
  • 268
  • 269
  • 270
  • 271
  • 272
  • 273
  • 274
  • 275
  • 276
  • 277
  • 278
  • 279
  • 280
  • 281
  • 282
  • 283
  • 284
  • 285
  • 286
  • 287
  • 288
  • 289
  • 290
  • 291
  • 292
  • 293
  • 294
  • 295
  • 296
  • 297
  • 298
  • 299
  • 300
  • 301
  • 302

Binding
between
elements
To
perform
a
business
process,
a
collaboration
can
communicate
with
connectors,
with
other
collaborations,
and
with
external
processes
from
which
it
receives
access
requests
through
the
Server
Access
Interface.
Binding
is
used
to
set
up
communications
between
the
collaboration
and
these
elements
when
the
collaboration
is
configured.
This
section
describes
the
concepts
for
binding.
The
tools
and
procedures
for
creating
the
bindings
are
described
later
in
this
guide
underChapter
9,
“Configuring
collaboration
objects,”
on
page
155).
Binding
a
trigger
A
collaboration
begins
a
processing
flow
when
it
is
triggered
to
do
so
by
the
arrival
of
a
business
object.
The
trigger
can
be
any
of
the
following:
v
A
business
object
from
an
event
published
by
a
connector
in
a
publish-and-subscribe
interaction
v
An
access
request
received
through
the
Server
Access
Interface
v
A
service
call
from
a
connector
To
allow
a
collaboration’s
business
processes
to
be
triggered,
you
must
bind
the
collaboration
at
configuration
time
to
an
element
that
will
supply
the
triggering
event
or
call.
Binding
is
done
between
the
collaboration
and
any
element
that
will
participate
in
that
collaboration’s
business
process,
but
only
one
element
can
be
bound
as
the
trigger.
Binding
for
events
When
you
configure
a
collaboration
at
your
site
to
be
triggered
by
events,
you
bind
it
to
a
connector
capable
of
publishing
the
triggering
event.
For
example,
you
might
specify
that
the
collaboration’s
Employee.Delete
event
comes
from
the
PeopleSoft
connector.
To
look
more
closely
at
this
relationship,
recall
that
the
connector
actually
consists
of
a
connector
controller
(which,
like
the
collaboration,
resides
in
the
InterChange
Server
Express)
and
a
connector
agent
(which
includes
the
client
connector
framework
and
an
application-specific
component,
and
is
separate
from
the
InterChange
Server
Express).
The
connector
controller
maintains
the
binding
information
and
provides
its
connector
agent
with
a
list
of
events
to
which
collaborations
have
subscribed.
When
relevant
application
operations
occur,
the
connector
agent
publishes
the
events
on
that
list
to
the
connector
controller.
The
connector
agent
sends
an
event
to
the
connector
controller
without
knowing
anything
about
its
ultimate
destination
at
a
collaboration.
The
connector
controller
is
therefore
an
intermediary
between
the
connector
agent
and
the
collaboration,
as
Figure
8
on
page
14
illustrates.
Chapter
1.
Overview
of
IBM
WebSphere
Business
Integration
Server
Express
13