Business Events

Release: R19 AMR

May 2019

Information in this document is subject to change without notice.

No part of this document may be reproduced or transmitted in any form or by any means, for any purpose, without the express written permission
of TEMENOS HEADQUARTERS SA.

© 2019 Temenos Headquarters SA - all rights reserved.

 Business Events

Table of Contents
Introduction 3
Purpose of this Guide 3
Intended Audience 3
Business Events Configuration 4
Architecture of Events 6
Configuring an Account Officer to receive Alerts 10
Configuring customer preferences to manage Alerts 11
Current Defined Event Types 12
Business Events Deal Processing 18
Subscription to an Event by an Account Officer 19
Subscription to an Event for an Account or Arrangement 20
Subscription to Events 21
Delivery 23
Business Event Services 24
TEC Subscribers 25
Delivery 26
AA Arrangement Service 27
AA Linked Arrangement 28

2
Business Events

Introduction
Purpose of this Guide
The Instant Messaging (aka Business Events) User Guide provide a profound insight
into configuration, working and usage of the Core Banking BE module.

Intended Audience
This User Guide is intended for Core Banking Customers, Internal Stakeholders and
those who use and implement the BE module.

3 Introduction
 Business Events

Business Events Configuration

Before delving into the details of the Alerts and Notifications functionality, it is
important to understand the significance of ‘Event Types’ or in other words, ‘Pat-
tern’ of events.
The purpose of the ‘Event Type’ is to allow implementations to add more events
without any additional code. At the same time, the Event type should not be at such
a high level and generic as to be able to fit 100 events into one bucket.
It is anticipated that the event types identified here may not cover absolutely every
event that could happen in a banking system and there could certainly be some
exceptions to these patterns.
The rationale is to prevent this minority of exceptions from impeding the per-
formance of the majority of most common events.
An event type is a classical grouping of similar events into a group. For example,
consider the following events.
When an account is credited and the credit amount is greater than 5,000 (“Large
Deposit”)
When an account is credited and the transaction code is a ‘Salary Credit’
Whenever an account is credited
All of these events can be logically grouped under an Event Type called “CR.TXN”
and supplemented with additional criteria based on values in the fields in respective
STMT.ENTRY records.
When an account is debited and the debit amount is greater than 5,000 (“Large
Withdrawal”)

Business Events Configuration 4

Business Events

When an account is debited and the Channel is ATM POS (Point Of Sale) purchase.
Whenever an account is debited:
All of these events can be logically grouped under an Event Type called “DR.TXN”
and supplemented with additional criteria based on values in the fields in respective
STMT.ENTRY records.
It is indeed possible to group all the above into one type called “TXN” but that
would move the level of grouping to one level higher, which in turn increases the
unnecessary processing that would be done by TEC every time an event occurs.
l Architecture of Events - how they are defined
l Configuring an Account Officer to receive Alerts
l Configuring customer preferences to manage Alerts
l Current Defined Event Types

5 Business Events Configuration

 Business Events

Architecture of Events
There are two underlying parameter tables used for Event Definition: these are
EB.EVENT.TYPE and TEC.ITEMS. These two are discussed below:

EB.EVENT.TYPE
EB.EVENT.TYPE is the touchpoint between the actual event happening in T24 and
the TEC.ITEMS configuration. T24 Model Bank supplies a number of ‘touchpoints’
whereby an event can be indicated to have happened.
The majority of touchpoints are instances where a table is updated. However, there
are also some touchpoints, which are not triggered from the update of a table – for
example, Direct Debit and Standing Order executions and failures.
For a list and explanation of these EVENT.TYPEs, click here.
When an EB.EVENT.TYPE is called, it can also supply the delivery instructions that
should result from this event type - an EB.ACTIVITY value is specified, which in turn
links to an EB.ADVICES record, which in turn link to the DE.MESSAGE functionality.

TEC.ITEMS:
This table handles both technical alerts (errors in processing) and business alerts
(information for customers and account officers about business events). As this wiki
relates to business alerts, we can discuss the business related fields here.
It is likely that the overall touchpoint is too high-level to be of use for determining
an event. For example, we may not want to know every time a record changes - but
we want to know when a particular field on that record changes.
Through TEC.ITEMS, the bank can fine-tune the nature of the event – we may not
want an event to be generated every time a ‘touchpoint’ (EB.EVENT.TYPE) is
triggered, but possibly under specific circumstances. It is to these fine-tuned cir-
cumstances that the user then subscribes. TEC.ITEMS clarifies the nature of the
Event through the following settings:
Subscriber
When an event occurs, through which medium should the alert be communicated?
Model Bank comes configured with the functionality to communicate this over the
DELIVERY system. In future, other subscribers such as Process Workflow or a Busi-
ness Activity Monitoring mechanism may be included.
Which Event type is being used? (i.e what is the underlying touchpoint) –
This is set in the EVENT.TYPE field.
Subscription Type
Can this event be monitored by customers, account officers, both, or is it man-
datory for everyone affected?- this is set in the SUBSCRIPTION.LEVEL field. There
are queries in model bank, and validation to ensure that internal subscribers
(account officers) cannot subscribe to external events, and vice-versa.

Business Events Configuration 6

Business Events

Field level specification

l Where an event relates to entry into a T24 table (this tends to be the main
source of events), what checking should the system perform to ascertain
whether an event has taken place? For example, events may be related to an
update to the ACCOUNT table (so update to ACCOUNT is the touchpoint) – but
different events can be derived from this, depending on whether it is the
WORKING.BALANCE or ACCOUNT.INACTIVE or even CURR.NO fields on
account. Additional considerations :
l An event might only occur depending on updates to two or more fields
– for example, an event might only be triggered if the
WORKING.BALANCE field changes and the CATEGORY.CODE is in the
range 1000 – 1999.
l Operands : Event functionality can compare new with old values to
determine whether an event has occurred. Therefore, along with the
usual operands (greater than, less than, begins with, ends with, equals,
does not equal, is/is not in the range of, etc) there are also com-
parative operands: changed, changed from, changed to.
l Where the EVENT.TYPE is based on a table, the same table should be
entered in the TABLE field.
l Along with being determined by one or more fields, an event may be
defined by a KEYWORD. See section on KEYWORDS for more inform-
ation

Subscriber Level Definitions

Events themselves may have subscriber (Customer or Account Officer) variables,
which determine whether the event has happened – so one customer may wish to
be alerted to an event when their working balance falls below 500, another may
wish to be alerted only when the working balance falls below 100. Whether a sub-
scriber is required to set their variable is set in the INHERIT field within the
FIELD.TYPE – INHERIT multivalue set.

Precedence
It is likely that some events may take precedence over others – for example, I may
have an event to alert me when my balance falls below 100, and another event,
which alerts me when my overdraft limit is exceeded. In this case, I might want to
only receive the second alert if a single transaction triggers both alerts. This is set
in the PRECEDENCE field.

One Time Subscription

An event might be a ‘one-time-only’ occurrence – for example, I may wish to be
alerted when a chequebook is issued, or a loan is authorized. Once this has
happened, and the alert has been issued, the event should be automatically ‘unsub-
scribed’ – as it would be unnecessary and inefficient for the customer to have to
unsubscribe to it. This would be specified in the ONE.TIME.SUB field.

7 Business Events Configuration

 Business Events

Event Severity
Severity – Each TEC.ITEMS can be classified with a severity level. This is used for
information/reporting purposes. Can be used to determine the alert carrier.

Active / Inactive
A TEC.ITEMS can be switched on/off for all subscribers through a STATUS field.
When it is set to ‘Inactive’ then this TEC.ITEM does not get triggered.

Keywords
Sometimes, it may not be possible to determine whether an event has happened
purely through looking at the fields that were used, and the values in them.
Examples of these could be an event being raised when:
A record is reversed (so event based on FUNCTION used).
A particular VERSION is used.
After the FIRST authorizer (not necessarily the final authorizer)
A particular CHANNEL is used (so an event occurs if channel A is used, but not chan-
nel B).
A particular APPLICATION is used.
To cover this requirement, it is possible to use Keywords rather than a specific
table. Keywords allowed are :
- !APPLICATION (Application)
- !V$FUNCTION ( Function)
- !PGM.VERSION( Version of the Application)
- !CHANNEL ( Channel defined in ofs.source)
- !AUTH.NO ( No of Authorisers)

Steps to Define an Event

To configure an event, apply the following steps:
Identify/Configure the message that should be sent (EB.ADVICES, EB.ACTIVITY).
Identify the ‘touchpoint’ behind the event. Ensure it has the correct message spe-
cified.
Create the TEC.ITEMS, specifying the touchpoint and the additional specifics to
identify when an event is triggered.
Once the event has been configured, to test, create an EB.ALERT.REQUEST to sub-
scribe to the above TEC.ITEMS record, including any variables that need to be
entered (due to the INHERIT flag being set on TEC.ITEMS), and update T24 in such a
way to trigger the EB.ALERT.REQUEST. Review the EVENT.LOG files to confirm that
an alert was triggered in line with the configuration.

Business Events Configuration 8

Business Events

Note, in order for events to be processed in order to generate alerts, the relevant
services need to be run. See the SERVICES section for more information.
Learning how to configure and use events is best explained by the following
examples.
For examples of how to use the Events functionality, see the related How To Guides.

9 Business Events Configuration

 Business Events

Configuring an Account Officer to receive Alerts

Account Officers can receive Alerts on Events in the same way that customers do.
However, as customers have the DE.CUSTOMER.PREFERENCE functionality to
receive alerts, Account Officers need to be associated with a Proxy Customer in
order to make use of the same functionality.Therefore, on ACCOUNT.OFFICER there
is a field CUSTOMER.ID through which, an Account Officer can be linked to a proxy
customer, where the Delivery Preferences have been set. A process workflow has
been configured for model bank to deliver this functionality.
When an account officer is linked with an Event, that request is stored on that
Account Officer record.

For step through examples of this, see the How To guides.

Link an Account Officer to an Event
Configure an Account Officer to receive alerts

Business Events Configuration 10

Business Events

Configuring customer preferences to manage Alerts

The customer can specify how they wish to receive alerts (messages triggered from
Events) through DE.CUSTOMER.PREFERENCES functionality.
To see how this is done through ModelBank, see “How To Subscribe to an Alert
through Internet Banking”.
The Account Officer can also use the same preferences to manage alerts (see Con-
figuring an Account Officer to receive Alerts and the associated How To guide)

11 Business Events Configuration

 Business Events

Current Defined Event Types

Event Type Description Value to be Sup-
plied
ACCOUNT When ACCOUNT is com- R.ACCOUNT (R.NEW
mitted as dynamic array)
ACCOUNTING.AVAILABLE.OD When Available Balance
is Overdrawn
ACCOUNTING.BALANCE.ABOVE When a Credit trans- R.ACCOUNT Before
action increases the bal- & After Image
ance
ACCOUNTING.BALANCE.BELOW When a Debit trans- R.ACCOUNT Before
action reduces the bal- & After Image
ance
ACCOUNTING.CHEQUE When a Cheque Trans- STMT.ENTRY
action happens
ACCOUNTING.CR.TXN When a Credit Entry is STMT.ENTRY
raised
ACCOUNTING.DR.TXN When a Debit Entry is STMT.ENTRY
raised
ACCOUNTING.INACTIVITY When the Account is STMT.ENTRY
marked Inactive
ACCOUNTING.INTEREST When Interest is cap- STMT.ENTRY
italized
ACCOUNTING.LIMIT When there is a Limit Custom Dynamic
Update Array. 2 Fields=Old
Value & New Value
ACCOUNTING.LOCKED.AMT When there is a short-
fall on Locked
ACCOUNTING.OVERDRAWN When a Debit trans- STMT.ENTRY
action makes the
account go OD
ACCOUNTING.RESTRICT When there is a Posting STMT.ENTRY
Restrict on Account
ACCOUNTING.STOP.PAYMENT When a Stopped STMT.ENTRY
Cheque is presented

Business Events Configuration 12

Business Events

AGE.OVERDUE Age Overdue Alert

AR.ACCOUNT.CHANGE.PRODUC- Change on condition of
T arrangement
AR.ACCOUNT.CREDIT When AR account is
credited
AR.ACCOUNT.DEBIT When an AR account is
debited
AR.CLOSE.ACCOUNT When an AR account is
closed
AR.CLOSURE.REQUEST When an AR account
closure is requested
AR.UPDATE.CUSTOMER Customer level change
in AR account
CANCEL.ARRANGEMENT Cancel arrangement
CHANGE.CHARGE Change charge alert
CHANGE.INTEREST Interest is changed in a Respective Property
Loan Arrangement Record (defined as
SOURCE TABLE)
CHANGE.PRODUCT Change Product Alert

CHEQUE.ISSUE When Cheque issue R.CHEQUE.ISSUE

record is committed (R.NEW as dynamic
array)
DD.DDI When DD Mandate is R.DD.DDI (R.NEW as
committed dynamic array)
DD.EXECUTION When a DD is Executed Custom Dynamic
Array. 1 Field = 1
(success) /0 (failure)
/-1 (retry failure)
DISBURSE.ARRANGEMENT Disbursement Alert
FUNDS.TRANSFER When a Funds Transfer R.FUNDS.TRANSFER
happens
ISSUE.BILL AA Lending Arrange- Respective Property
ment Record (defined as
SOURCE TABLE)
ISSUE.CHASER Issue chaser Alert

13 Business Events Configuration

 Business Events

MATURE.ARRANGEMENT Loan Arrangement Respective Property

matures Record (defined as
SOURCE TABLE)
NEW.ARRANGEMENT New Loan Arrangement Respective Property
Record (defined as
SOURCE TABLE)
NEW.ARRANGEMENT.DAO New arrangement alert
for DAO
PAYMENT.STOP When Payment stop is R.PAYMENT.STOP
committed (R.NEW as dynamic
array)
PAYOFF.ARRANGEMENT Payoff Alert
PAYOUT.ARRANGEMENT Payout arrangement
PWM.CANCEL.ORDER Securities order can-
celled
PWM.EVENTS.CORPACTIONS Corporate Actions
PWM.EXECUTED.ORDER Securities Order
executed
PWM.EXPIRED.ORDER Securities Order
expired
PWM.HOLDING.BREACH Overnight RESTRICTION
trigger
PWM.INV.STRATEGY.CHANGE Investment Strategy
Changed
PWM.MARGIN.CALL Margin Call on Your
Portfolio
PWM.MARGIN.CALL.BUFFER Margin Call buffer
PWM.MARGIN.CALL.MOVEMEN- Margin Call Movement
T
PWM.MARKET.RATING.CHANGE Investment Recom-
mendation
PWM.MIFD.EX.EXCHANGE Exchange not MIFID
complaint
PWM.MIFD.SUITABILITY MiFID color
PWM.PORTFOLIO.AMEND Portfolio Amend

Business Events Configuration 14

Business Events

PWM.PORTFOLIO.BLOCK SECURITY BLOCK

PWM.PRICE.CEILING PWM.PRICE.CEILING
PWM.PRICE.MOVEMENT PWM.PRICE.MOVEMEN-
T
PWM.RESPMAN.COUPON Coupon
PWM.RESPMAN.FEES.ADV Advisory Fee
PWM.RESPMAN.FEES.PERF Performance fees
PWM.RESPMAN.FEES.SAFE Safekeep Fee
PWM.RESPMAN.REDEPTION Redemption
PWM.SEC.OPEN.ORDER Sec open order
PWM.STRATEGY.OUT.OF.LINE Strategy out of line
PWM.STRUCTURED.EVENT Structured Event
PWM.STRUCTURED.TRADE Structured Product
Trade
RECEIVE.PAYMENT Receive Payment
REDEEM.ARRANGEMENT Redeem Arrangement
RESET.ARRANGEMENT Reset Arrangement
alert
ROLLOVER.ARRANGEMENT Rollover arrangement
STANDING.ORDER When STO is committed R.STANDING.ORDER
(R.NEW as dynamic
array)
STO.EXECUTION When an STO is Custom Dynamic
Executed Array. 1 Field = 1
(success) /0 (failure)
/-1 (retry failure)
DISBURSE When a disbursement Respective Property
Record (defined as
SOURCE TABLE)
ROLLOVER When a contract is Respective Property
rolled over Record (defined as
SOURCE TABLE)

15 Business Events Configuration

 Business Events

APPLY- A repayment is made Respective Property

PAYMENT.PAYMENT.RULES on a Loan Arrangement Record (defined as
SOURCE TABLE)
UPDATE.CHARGE Charge is applied on a Respective Property
Loan Arrangement Record (defined as
SOURCE TABLE)
CHANGE.SETTLEMENT AA Lending Arrange- Respective Property
ment Record (defined as
SOURCE TABLE)
INTERNET.SERVICES AA Internet Banking Respective Property
Arrangement Record (defined as
SOURCE TABLE)
POSITION.DR.TXN When a Stock Sale is R.SECURITY.TRANS
made (for both SC &
DX)
POSITION.BALANCE.ABOVE When a Stock Purchase R.SECURITY.POSITIO-
increases the position N Before & After
Image
POSITION.BALANCE.BELOW When a Stock Sale R.SECURITY.POSITIO-
reduces the position N Before & After
Image
POSITION.BALANCE When a transaction R.SECURITY.POSITIO-
updates the position N
POSITION.OVERDRAWN When a Short Sell is R.SECURITY.POSITIO-
made N
DEPOSITS AA Deposits Arrange- Respective Property
ment Record (defined as
SOURCE TABLE)
PAYOFF Loan Arrangement is Respective Property
paid-off Record (defined as
SOURCE TABLE)
AGE-OVERDUES Loan status goes to Respective Property
Overdue Record (defined as
SOURCE TABLE)
ACCOUNTING.BALANCE When an entry updates R.ACCOUNT
the balance

As Alerts makes significant use of other T24 functionality, there is significant con-
figuration that can be applied, some of which is specific to Alerts / Events, and

Business Events Configuration 16

Business Events

some of which is generic existing T24 functionality. Configuration includes:

Delivery Instructions that should take place when an event occurs (EB.ADVICES,
EB.ACTIVITY, DE.MESSAGE.TYPE etc) – and EB.EVENT.TYPE, which links the event to
the Delivery Instructions – note, this is linking to generic Delivery functionality.

17 Business Events Configuration

 Business Events

Business Events Deal Processing

There are two ways in which an end-user (either an Account Officer or a Customer)
can be alerted to an event
A TEC.ITEM is created with a SUBSCRIPTION.LEVEL of MANDATORY. In this case,
the customer / account officer associated with the transaction automatically gets
an alert when the TEC Item is triggered – they do not need to subscribe, and they
cannot unsubscribe, from this event. As it is only possible to subscribe to an event
related to an ACCOUNT or an ARRANGEMENT, so for any mandatory event the sys-
tem always uses the customer / account officer of the account/arrangement.
An EB.ALERT.REQUEST record is created for that Account / Arrangement, or
Account Officer. In this, the TEC.ITEMS is specified, indicating which alert this
Account / Arrangement / Account officer wishes to follow, and also any variables
associated with the TEC.ITEMS (e.g if the Alert is triggered when the balance goes
below a certain amount, what that amount should be etc). Whenever an event
occurs to this Account/arrangement that has an EB.ALERT.REQUEST, the Account
Officer / Customer is sent an alert in line with the filters set on the TEC.ITEMS.
l Subscription to an event by an Account Officer
l Subscription to an event for an Account or Arrangement
l Subscription to Events

Business Events Deal Processing 18

Business Events

Subscription to an Event by an Account Officer

An account officer is likely to want to know when significant events occur which is
of interest to their customers. As with customers, the Account officers can only sub-
scribe to events relating to an Account / Arrangement – they cannot subscribe at
the Customer or Portfolio level. However, whenever an event occurs to the account
or arrangement, the system determines who the account officer is, and if they have
subscribed to this event, an alert is raised – again, based on the settings on the
TEC.ITEMS SUBSCRIBER field and EB.EVENT.TYPE EB.ACTIVITY field (if set).
To subscribe, create an EB.ALERT.REQUEST, specify the event to be subscribed to,
and the Account Officer subscribing.

19 Business Events Deal Processing

 Business Events

Subscription to an Event for an Account or Arrange-

ment
While subscriptions cannot be done on a customer basis – they can only subscribe
to events affecting their accounts and/or arrangements – the system automatically
determines the customer based on the account/arrangement, and delivers a mes-
sage to the customer based on the settings on the TEC.ITEMS SUBSCRIBER field and
EB.EVENT.TYPE EB.ACTIVITY field (if set).

Create a new EB.ALERT.REQUEST record, specify the event that should be linked,
and the Account or the Arrangement that the event is linking to.

Business Events Deal Processing 20

Business Events

Subscription to Events
Subscription occurs through the application EB.ALERT.REQUEST.
The TEC.ITEMS refinement to EB.EVENT.TYPE is placed in the EVENTS field.
If the event is being subscribed to by a customer, either an ACCOUNT or
ARRANGEMENT is placed in the Contract Ref field.
If the event is being subscribed to by an account officer, the account officer is
placed in the ACCOUNT.OFFICER field.

If the TEC.ITEMS record specified in the Event field has one or more fields which
requires an ‘inherited’ value, these need to be provided. The system automatically
multivalues the Value field to reflect the values that must be entered to satisfy the
event definition.

21 Business Events Deal Processing

 Business Events

Business Events Deal Processing 22

Business Events

Delivery
Event Management links to DELIVERY through the specification of an EB.ACTIVITY
record in the EB.EVENT.TYPE setting – so when this event type is triggered, this
delivery setting is consulted to determine how the alert should be set.
Delivery module can be set as a Subscriber to an Event (TEC.ITEMS) by setting the
field SUBSCRIBER as DELIVERY.ALERT.
When an Event is Published, the Delivery Alert as a Subscriber converts the Event
data as standard DE Handoff data and hands it off to the Delivery module which
then takes care of formatting and delivering the notification.

For more information about delivery, refer to ‘How to Change a Delivery Alert Mes-
sage’ guide.

23 Delivery
 Business Events

Business Event Services

The following services are associated with Business Events.
Of the below, only EVENT is specific to business events. The others relate to other
functionality in the system, however they are necessary for events to generate deliv-
ery messages.

Service Name What the service does COB Trigger Dependent

Stage / Related
/ Processes
Online
EVENT Needs to be run in order Online
to process the events.
When this service is run,
records from
FBNK.EVENT.LIST are
selected and processed,
to create Delivery Mes-
sages, or whatever has
been specified by the
TEC.ITEMS and
EVENT.TYPE
OFS.MESSAGE.SERVICE Supports delivery, to cre- Online
ate messages generated
through Events
SECUREMSG.OUT Generates secure mes- Online
sages
EMAIL.OUT Generates emails Online
SMS.OUT Generates SMS Online

Business Event Services 24

Business Events

TEC Subscribers
This section covers the following sub-topics:
l Delivery
l AA Arrangement Service
l AA Linked Arrangement

25 TEC Subscribers
 Business Events

Delivery
Event Management links to DELIVERY through the specification of an EB.ACTIVITY
record in the EB.EVENT.TYPE setting – so when this event type is triggered, this
delivery setting is consulted to determine how the alert should be set.
Delivery module can be set as a Subscriber to an Event (TEC.ITEMS) by setting the
field SUBSCRIBER as DELIVERY.ALERT.
When an Event is Published, the Delivery Alert as a Subscriber converts the Event
data as standard DE Handoff data and hands it off to the Delivery module which
then takes care of formatting and delivering the notification.

For more information about delivery, refer to ‘How to Change a Delivery Alert Mes-
sage’ guide.

TEC Subscribers 26
Business Events

AA Arrangement Service
Services that are offered to Accounts are accessed via T24 Applications. Each
product is defined in T24 using the Application and the Application Type. For
example FT application has FTTC , STO has STO.TYPE, RS has AC.SWEEP.TYPE. There
can be a need to restrict such services being offered to Account.
EB.EVENT.TYPE is created for such services using Application name – SERVICE. For
instance AC.ACCOUNT.LINK – SERVICE. TEC.ITEMS can be created for such Service
events with Inline Subscriber. Such TEC.ITEMS with inline Event types (Application-
SERVICE) are used in AA to evaluate the service in product. Example Maintenance
Sweep allowed or restricted for an account. The TEC items created for Events and
are mapped to AA activity via Activity Mapping. Thus Events on external accounts
are mapped to activities in AA. These Activities can be fully or partially restricted
using Facility Property Class. Facility Property class is used to restrict or provide the
facility as part of a package for the account. To learn in detail please read Facility
property class.

On setting up a Account Sweep Facility, Before the unauthorised record is written,

the Account is verified for the facility being available.
TEC.INLINE.APPICATION.HANDOFF collects the information required for inline pro-
cess.
TEC.RECORD.EVENT would be called further (this is common for both inline and
online processing) and post which events are published.
The PUSH.API configured executes the selection criteria and maps the information
extracted from external application to the Activity in AA (including non financial
activities).

27 TEC Subscribers
 Business Events

AA Linked Arrangement
AA Linked Arrangement can be set as a Subscriber to an Event (TEC.ITEMS) by set-
ting the field SUBSCRIBER as LINKED.ARRANGEMENT.
Whenever an Event is raised from an Arrangement the Linked Arrangement Sub-
scriber API checks if the Arrangement is linked to Bundle and if the Bundle is inter-
ested in this Event (that is if this Event is mapped to a Bundle Activity in the
Bundle’s Activity Mapping condition). If there is a mapping then it resolves the Activ-
ity name, builds an OFS for AA Arrangement Activity and hands it off to the AA Pro-
cess Activities Service.

TEC Subscribers 28