![](bg6.png)
monitoring results for each process instance execution
considering the data shown in the first two frames.
Figure 9: Dashboard prototype – BLA monitoring details.
3 EVALUATION
The loan process model in Figure 1 was explored to
evaluate the proposed component. The BLA “Perfor-
mance efficiency
7
≥ 95%” (associated with the activ-
ities Assess elegibility, Prepare acceptance pack and
Send acceptance pack) was chosen for this evalua-
tion. This BLA was defined considering the rules de-
fined by the BLA meta-model on which the proposed
component is primarily based (cf. Section 2.1). The
details of the BLA are not shown graphically in the
process model, but only in terms of the element prop-
erties in the tool. Some of these details can be seen
in the prototype presented herein (cf. Figure 8). In
Figure 8, it is possible to consult, for example, the
different thresholds for the application of penalties in
case of non-compliance with the target and different
thresholds to be awarded bonuses in case the goal is
reached more satisfactorily than expected. For exam-
ple, for this BLA, the target is 95%, with a tolerance
of 5% and three penalty levels (< 90%, < 80% and <
75%). The lower the level of performance obtained,
the higher the penalty applied. On the other hand,
there are two levels of bonus (≥ 95% and ≥ 98%);
the higher the level, the higher the bonus.
Using the proposed infrastructure (cf. Figure 5)
and component (cf. Figure 4), the process was exe-
cuted and monitored. The process model in Figure 1
7
Per the adopted NFR nomenclature, “performance ef-
ficiency” means: degree to which a process can efficiently
use an amount of resources (such as software, products and
hardware) under stated conditions (Castro et al., 2019).
was implemented in WS-BPEL as in Figure 10. The
dotted red line highlights the code fragment corre-
sponding to the implementation of the three process
activities associated with the BLA under analysis.
Four services were used to perform these three activ-
ities (two services for activity Assess elegibility, one
service for Prepare acceptance pack and one service
for Send acceptance pack). To achieve the target of
this BLA, three SLAs were defined: ‘response time’
and ‘availability’ for the first service used to exe-
cute Assess eligibility and ‘availability’ for the service
used to execute the activity Send acceptance pack
8
.
Some details of each SLA are in Figures 8 and 9, in-
cluding their targets, different penalty thresholds and
different thresholds for granting bonuses, and maxi-
mum number of attempts per process instance. The
Fixture Factory
9
tool was used to generate random
data (i.e., the mocks) to simulate the SLA processing.
Figure 11 shows a consolidated view of the re-
sults of the monitoring simulation for the loan pro-
cess. The BLA is considered failed for an instance
execution if any of the associated SLAs are finalized
failed for that execution. The third SLA, referring to
the second service, is only evaluated if the first ser-
vice could be executed, i.e., if it was available. Per
Figure 11, one can observe that the scenarios relevant
for the business areas are different from IT. For ex-
ample, an SLA that fails may not necessarily reflect
a failure in the corresponding BLA. Thus, the busi-
ness area needs not to be involved in minor technical
issues, which can be handled in isolation by IT. The
calculations of each BLA and each SLA is performed
independently although the BLA calculation consid-
ers the result of SLAs that are associated with it. Each
SLA presents an isolated view specific to IT manage-
ment and the calculation to determine whether its tar-
get is being reached is performed in a parametrized
way for each SLA. For example, for the SLA Re-
sponse Time, the calculation is being done every five
executions of the associated service. The same is oc-
curs for BLAs, which in this case is being done every
10 process instance executions. In Figure 11, results
are shown for 20 instance executions, which enabled
to calculate the BLA average value twice, whose re-
sults were 90% (Warning) and 70% (Failed Level 3).
Also, depending on the nature of the service, it is pos-
sible to parametrize the maximum number of attempts
it will retry, in case its SLA is failed, before the cor-
responding BLA is considered having failed.
An example of a situation where a technical prob-
8
The definition of which services should have SLAs as-
sociated and the QoS attributes and levels best suited to
achieve a BLA goal are outside the scope of this paper.
9
http://github.com/six2six/fixture-factory
Monitoring of Non-functional Requirements of Business Processes based on Quality of Service Attributes of Web Services
593