Value Added Service
(VAS)
Technologies
– Software AG webMethods
– webMethods Business Process Model Suite.
– CA LISA, soapUI and Quality Center
Description:
make online recharge and purchase airtime for his cell number using the value added services from the bank. As per the above, the user is provided with the option to recharge using, making a call to customer support representative, using mobile app on his mobile device, or using the online banking option. Behind the presentation layer, there are flows defined in BPM which triggers and choreograph the services. The blog is specifically to explain how these services are tested at component level and later through the BPM layer before them given to the functional team for final round of testing. There were different services developed to provide this functionality to the client. All the services were divided into technical from the domains, business services from the ESB, Chorography in BPM and lastly the presentation service which gives the result back to the user.
unique payment reference when a successful payment is done. In case of failure to do payment
the service will respond with respective error message or a blank. The service will debit the
amount from the user account and later pass the message to ESB to send it to third party.
Request from 3rd Party to ESB
4.updateAuditTrail:
Client Notification request
DocServices Format
Project Goal
–
Create new functionality on online & mobile digital channels to
allow clients to
purchase value added services.
– Create a secure network connection between Bank and the vendor.
– Create a settlement and reconciliation process.
– Create a secure network connection between Bank and the vendor.
– Create a settlement and reconciliation process.
Technologies
– Software AG webMethods
– webMethods Business Process Model Suite.
– CA LISA, soapUI and Quality Center
Description:
make online recharge and purchase airtime for his cell number using the value added services from the bank. As per the above, the user is provided with the option to recharge using, making a call to customer support representative, using mobile app on his mobile device, or using the online banking option. Behind the presentation layer, there are flows defined in BPM which triggers and choreograph the services. The blog is specifically to explain how these services are tested at component level and later through the BPM layer before them given to the functional team for final round of testing. There were different services developed to provide this functionality to the client. All the services were divided into technical from the domains, business services from the ESB, Chorography in BPM and lastly the presentation service which gives the result back to the user.
1.updatePayment:
The
payment method will receive request for the VAS Purchase and will respond with
a unique payment reference when a successful payment is done. In case of failure to do payment
the service will respond with respective error message or a blank. The service will debit the
amount from the user account and later pass the message to ESB to send it to third party.
Request from GUI to ESB
Request from ESB to 3rd
party
Request from 3rd Party to ESB
Request from ESB to GUI
2.updatePaymentReversal:
The
payment reversal operation is called when a VAS purchase fails, the service will be
triggered
and will roll back the transaction and update the different systems for
roll back.
This
will also credit the amount back to the user account.
3.getNotificationAndPreferenceDetails:
This operation is used to provide notifications addresses and preference of the client for transactions. Service is expected to be used for VAS purchase notifications done from accounts for client under a profile. The service picks the preferred method of notification as set by the client. This is available in the online banking notification preference which user defines, like SMS / Email..
This operation is used to provide notifications addresses and preference of the client for transactions. Service is expected to be used for VAS purchase notifications done from accounts for client under a profile. The service picks the preferred method of notification as set by the client. This is available in the online banking notification preference which user defines, like SMS / Email..
4.updateAuditTrail:
This
service exposes audit trail functionality to allow client systems to write audit
trail
information
for VAS Purchases. This service uses information
in JSON message format which is
updated
in audit trial table of Online banking system. This helps to keep track of
all the
transactions
performed and helps to troubleshoot in case of transaction failure.
5.updateVASGatewayForPurchase:
This
service sends the request to the
third party which process the request and credit the
amount
to the cell. The process from the third party and the actual service
provider is out of
scope
as its already in production and is used by other banks. To keep the seamless
transaction between
the third party and the actual service provider is the responsibility
of third
party
as they have their own contracts for the same. Teams responsibility was to test
the
message
is converted in the format which is expected by the third party. This is done
by
validating
the logs which keep track of the message converted and details around what
message
is send to them.
6.sendVASCommunicationToClient:
Once the transaction is successful / failed
notification will be send to the client of the
same
in the preferred mode which client had already set in his online banking
profile. This is
done
again by another third party. This is out of scope as the same is already in
production for
different
client notifications for transactions. Responsibility over here is to test the
message is
delivered
to Document Services Message Queue (DSMQ) by validating in audit database of DSMQ.
Client Notification from ESB to DocServices
Message which is send from BPM via ESB to doc
services which delivers the notification to the client
Message which is converted, send from ESB to doc
services
Client
Notification DocServices database validation
Audit tables of doc services which processes the message and send it to
the third party so the same can be delivered to banking client
Service Virtualization of Third
Party to continue testing
The
biggest challenge for testing was unavailability of third party services,
environment constraint, as they have Development, Testing and Production were
as we have Development, Testing, Staging/UAT and Production. Because of this
testing was delayed. All the other systems were under control and within bank.
Due to this different team were impacted like development, Service testing
team, functional testing team and also the delivery dates for the project to Go
Live. Each time the messages were to be confirmed with the third party team
that they have received and consumed the messages successfully. This was a
bottle neck as the communication was through call/mail and the teams have to
wait till confirmation received. To overcome this, it was decided to virtualize
the third party system to continue development and testing. CA LISA was the
identified tool used to virtualize the third party service.
The communication between ESB and 3rd Party was
using message queue. ESB used to convert the message as per third party format
and post the message to outbound queue which used to be processed and placed at
third party inbound queue. The response was also in the same format from third
party queue to ESB inbound queue. To make the transaction seamless and without
any hiccups the transaction was virtualized. Proxy queues were created where
the LISA Virtualization recorder was placed which used to read the message and
later pass to outbound queue and in same way recording was done to incoming
message/response from third party. Once all the transaction was recorded the
queue details were changed and virtual service was deployed in LISA VSE all the
messages were processed with virtual service and response was sent back. This
helps the team to continue with their development and testing and all the
services and transaction within the bank environment were tested thoroughly and
were ready for deployment. Few rounds of tested was also done with the third
party to confirm the messages are processed as expected.
