IBM E02HMLL-I Implementation Guide - Page 179

Pause, critical, error, occurs, Maximum, number, concurrent, events, Persist, service, transit,

Get IBM E02HMLL-I - WebSphere Business Integration Server Express PDF manuals and user guides View all IBM E02HMLL-I manuals
Add to My Manuals
Save this manual to your list of manuals

Page 179 highlights

the design of the collaboration template, so reference the documentation for the specific collaboration template for information on how it approaches e-mail notification. Pause when critical error occurs Errors can occur that prevent a collaboration from having its business object requests processed by connectors to which it sends those requests. Some such errors are: v Inability of the connector to log in to the application. v A time-out in the communication between the connector and the application. v A connector agent changing to an unknown state. If these types of errors occur, the collaboration sends the request to the connector but then the flow fails because of the problem. This happens for any request sent until the problem is resolved, and can result in a large number of failed flows for the interface if the transaction volume is high and the error persists for a significant amount of time. You can configure a collaboration object so that it stops sending requests to a connector after a request fails due to a critical error. To do so, enable the Pause when critical error occurs checkbox. For more information on critical errors, a collaboration object's response to them, and the functionality of this feature, see the System Administration Guide. Maximum number of concurrent events You can configure collaboration objects to process multiple event-triggered flows concurrently, which can improve throughput for the interface. To do so, set the Maximum number of concurrent events drop-down menu to the number of events between 0 and 9999 that you want the collaboration object to process concurrently. To truly receive the benefit of this collaboration ability you must also configure other components that participate in the interface to behave similarly. For more information, see "Implementing concurrent processing of event-triggered flows" on page 279. Persist service call in transit state It is possible for an error to occur after a collaboration has sent a business object request to any destination connectors to which it is bound and before it has received a response from them as to whether or not they successfully processed the request in their respective applications. If the connectors were unable to process the request then it needs to be processed again when the error is resolved. If the connectors were able to successfully process the request, though, and are in the process of sending InterChange Server Express a notification of that successful processing when the error occurs then InterChange Server Express would not receive the notification. The last record of the state of the request would indicate that the request still needs to be processed. As a result of this inaccurate state record the request would be processed a second time, resulting in duplicate data. To guard against this complication when configuring non-transactional collaborations you can enable the Persist service call in transit state checkbox. This causes InterChange Server Express to persist any business object requests that are in transit to destination applications when an error occurs. The requests are not sent when the system recovers, reducing the risk of the request being processed Chapter 9. Configuring collaboration objects 167

  • 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
the
design
of
the
collaboration
template,
so
reference
the
documentation
for
the
specific
collaboration
template
for
information
on
how
it
approaches
e-mail
notification.
Pause
when
critical
error
occurs
Errors
can
occur
that
prevent
a
collaboration
from
having
its
business
object
requests
processed
by
connectors
to
which
it
sends
those
requests.
Some
such
errors
are:
v
Inability
of
the
connector
to
log
in
to
the
application.
v
A
time-out
in
the
communication
between
the
connector
and
the
application.
v
A
connector
agent
changing
to
an
unknown
state.
If
these
types
of
errors
occur,
the
collaboration
sends
the
request
to
the
connector
but
then
the
flow
fails
because
of
the
problem.
This
happens
for
any
request
sent
until
the
problem
is
resolved,
and
can
result
in
a
large
number
of
failed
flows
for
the
interface
if
the
transaction
volume
is
high
and
the
error
persists
for
a
significant
amount
of
time.
You
can
configure
a
collaboration
object
so
that
it
stops
sending
requests
to
a
connector
after
a
request
fails
due
to
a
critical
error.
To
do
so,
enable
the
Pause
when
critical
error
occurs
checkbox.
For
more
information
on
critical
errors,
a
collaboration
object’s
response
to
them,
and
the
functionality
of
this
feature,
see
the
System
Administration
Guide
.
Maximum
number
of
concurrent
events
You
can
configure
collaboration
objects
to
process
multiple
event-triggered
flows
concurrently,
which
can
improve
throughput
for
the
interface.
To
do
so,
set
the
Maximum
number
of
concurrent
events
drop-down
menu
to
the
number
of
events
between
0
and
9999
that
you
want
the
collaboration
object
to
process
concurrently.
To
truly
receive
the
benefit
of
this
collaboration
ability
you
must
also
configure
other
components
that
participate
in
the
interface
to
behave
similarly.
For
more
information,
see
“Implementing
concurrent
processing
of
event-triggered
flows”
on
page
279.
Persist
service
call
in
transit
state
It
is
possible
for
an
error
to
occur
after
a
collaboration
has
sent
a
business
object
request
to
any
destination
connectors
to
which
it
is
bound
and
before
it
has
received
a
response
from
them
as
to
whether
or
not
they
successfully
processed
the
request
in
their
respective
applications.
If
the
connectors
were
unable
to
process
the
request
then
it
needs
to
be
processed
again
when
the
error
is
resolved.
If
the
connectors
were
able
to
successfully
process
the
request,
though,
and
are
in
the
process
of
sending
InterChange
Server
Express
a
notification
of
that
successful
processing
when
the
error
occurs
then
InterChange
Server
Express
would
not
receive
the
notification.
The
last
record
of
the
state
of
the
request
would
indicate
that
the
request
still
needs
to
be
processed.
As
a
result
of
this
inaccurate
state
record
the
request
would
be
processed
a
second
time,
resulting
in
duplicate
data.
To
guard
against
this
complication
when
configuring
non-transactional
collaborations
you
can
enable
the
Persist
service
call
in
transit
state
checkbox.
This
causes
InterChange
Server
Express
to
persist
any
business
object
requests
that
are
in
transit
to
destination
applications
when
an
error
occurs.
The
requests
are
not
sent
when
the
system
recovers,
reducing
the
risk
of
the
request
being
processed
Chapter
9.
Configuring
collaboration
objects
167