transaction process

1. TRANSACTION MIDDLEWARE
2.0 Development
Transactions Advanced

2. Transactions Advanced
• This lesson gives you some more detailed understand about the
transaction-processing.
• After completing this lesson, you should be able to:
• Desribe the concept of TXM‘s multi-channel-architecture
• Describe the the role of a client-connector and it‘s main tasks
• Objectives

3. PC/E Architecture
Client
Connector
EIS Protocol
Handler
Session Bean
EIS Logics
EIS Logics
Transactions
BusinessLogic
Journal Bean
Journal
Journal Transformer
Channel Bean
Standard
Develop
Configure
EIS Connector
Card Handling
Bean

4. Channel Bean

5. What is the Channel-Bean?
The (SelfService) ChannelBean …
 abstracts the channel-specific concerns (e.g. card-handling)
 is the main entry point to start transactions for client connectors
 creates “Proxy-Objects“ for the transaction EJBs
 is a registry for all supported transactions (transactions are registered via binding-
annotation)
 journalizes transactions automatically (on the way back to include responses)
 allows intercepting all transactions

6. Transaction-Binding
• Transactions are bound to the Channel-Bean via a binding-annotation
• same concept as binding an EIS-logic to the EIS-ProtocolHandler
@Singleton
@ConcurrencyManagement(ConcurrencyManagementType.BEAN)
@TransactionManagement(TransactionManagementType.BEAN)
@Local({IPCELoadPrepaidLogic.class})
@PCEBusinessLogic(channelId=PCEChannelConstant.CHANNEL_CONSTANT_SELFSERVICE_ID)
@Specializes
public class TRLoadPrepaidBean extends PCELoadPrepaidBean {...}

7. Channel-Bean as a Transaction-Proxy

8. TXM‘s multi-channel architecture
• When talking about „the channel-bean“, we
usually refer to the Self-Service Business
Channel-Bean (server-sb.jar).
• But there are other channels:
• POS Channel
• Mobile Channel
• Network Channel
• Service Channel
• What channels do exist?

9. Client-Connector Basics

10. Client Connectors
EIS Protocol
Handler
Session Bean
EIS Logics
EIS Logics
Transactions
BusinessLogic
Journal Bean
Journal
Journal Transformer
Channel Bean
EIS Connector
Card Handling
Bean
Fat-Client
Connector
NDC
Connector
PCE Connect
Issuer
Connector
SmartClient
Connector
WebService
ClientConnector

11. What is the Client-Connector?
The Client-Connector abstracts the client-specific concerns like
 converting between client-protocol and server business-objects and APIs
 transactions
 commands
 events
Additionally, performs tasks that need to stay close to the entry-point of the server like
 transaction-number counting
 session- and transaction-consistency
 session- and transaction-persistence
 marking of sensitive data (masked in logs and traces)
 Detecting stale threads

12. Cluster-wide transaction-state synchronization via
Database
• Datastorage component handles cluster-wide synchronization of the
consumer-session (PCESessionContext) and thus also of the
transaction-state.
• Triggered by the client-connector
• The state is sychronized via the database.
Client
Connector Channel Bean
DATASTORAGE
After: Serialize & Write
SessionContext
Before: Read &
Deserialize
SessionContext
Don‘t put too much data (binary data; e.g. check images) into you objects/mixins.
It gets setrialized and will put pressure on the database.

13. Session-Context Update
• public class PCELoadPrepaidBean extends PCEBusinessLogicBase implements IPCELoadPrepaidLogic
• {
• public PCELoadPrepaidAuthorizeResponse authorize (PCELoadPrepaid loadprepaid, PCELoadPrepaidAuthorizeRequest request)
• throws PCEException {
• // Initial phase
• loadprepaid.setAuthorizeRequest(request);
• // Business Logic…
• // EISProtocolHandler call always even if there is a response already
• response = createEisProtocolHandler().authorize(loadprepaid, request);
• loadprepaid.setAuthorizeResponse(response);
• // return phase:
• return loadprepaid.getAuthorizeResponse();
• }
• It is the job of the business-logic to update the session/transaction-context.

14. The Datastorage
• Serialization is done via kryo (github.com/EsotericSoftware/kryo).
• UKA used in the past.
• Serialization method
1
Do you see data in the DATASTORAGE table after executing LoadPrepaid.groovy?
If not, why?

15. Datastorage
• How to delete the session-state aka „Restart Data“?

16. TRANSACTIONS ADVANCED
This lesson gave you some more detailed
understand about the transaction-processing.
In this lesson you should have learned to:
• Desribe the concept of TXM‘s multi-channel-
architecture
• Describe the the role of a client-connector and
it‘s main tasks
• Summary

17. Advanced Concepts

18. Advanced Transaction Processing
• How to implement cross-cutting logic for multiple transactions?
• How to implelement logic that does not contribute to the transaction-
response?
• E.g. Notifications-style calls, fire-and-forget, …
• How to implement logic that can run asynchroneous?
• Some of the tools you have:
• Channel Interceptors (synchroneous)
• Journal Appenders (synchroneous & asynchroneous)
• Reprocessor
• Async Transaction-Invocation
• Motivation

19. Channel Interceptor
• API to attach cross-cutting logic to the transaction-pipeline at the channel-
bean.
• e.g. logic that needs to be invoked for multiple/all transactions
• Examples from product
• Counter-Service
• Journal-Service
• Accounting-Periods
• Fee-Service
Details in programmers-manual section „The PCEChannelInterceptor”:
ProgrammerManual_PCESRV_Howto_007_Comment.pdf

20. Asynchroneous transactions
• Requirement: For doing withdrawal transactions against the host, a
customer-specific ID is needed. This ID can be retrieved from a system by
the bank via a SOAP-call. Providing the card‘s track2-data will return the
ID. Unfortunately, the SLA for the system allows it to take 3 seconds to
process. The customer does not want us to block the ATM-facing
transactions for the duration of this call.
• Idea:
• → Spawn an asynchroneous call during login (we have the track2-data at
this point in time already)
• → Fetch the result in the Withdrawal.authorize
• Example

21. Async Transaction-Invocation
• Invoke business transactions asynchroneusly…
• via channel-bean
• directly via business-logic
• via EIS Protocol Handler only
• Backed by Hystrix Thread-Pools.
Details in programmer‘s manual. See section „Using asynchronous processing with PC/E”:
ProgrammerManual_PCESRV_Howto_007_Comment.pdf

22. Async Transaction-Invocation
• // create a reference to execute an AccountSelection asynchronous via the self
• // service channel bean
• private static IPCEAccountSelectionLogic asyncChannel =
PCEAsynchLogicFactory.getAsynchBusinessLogicViaChannel(IPCEAccountSelectionLogic.class,
PCEServerSBChannelConstant.SELFSERVICE_BUSINESS);
• // create a reference to execute an AccountSelection asynchronous without to
• // invoke a channel bean
• private static IPCEAccountSelectionLogic asyncDirect =
PCEAsynchLogicFactory.getAsynchBusinessLogicDirect(IPCEAccountSelectionLogic.class);
• // create a reference to execute an AccountSelection asynchronous without to
• // invoke a business logic
• private static IPCEAccountSelectionLogic asyncEISPHSTP =
PCEAsynchLogicFactory.getAsynchEisPhLogic(IPCEAccountSelectionLogic.class,PCESTPComponentConstant.EIS_STP);
• API – getting the transaction-proxy

23. Async Transaction-Invocation
• // 1. invoke asynchroneously
• PCEAccountSelectionResponse response =
asyncAccessObject.selectSource(accountSelectionTransaction,
• accountSelectionSelectSourceRequest);
• // 2. check for a result but do not wait/block
• response = response.getResponseFuture(PCEAccountSelectionResponse.
• class).get(0);
• System.out.println(response);
• // 3. check for a result and wait the maximum configured asynchronous
processing time
• response = response.getResponseFuture(PCEAccountSelectionResponse.
• class).get();
• System.out.println(asyncResponse);
• API – getting a response