This specification describes the ofc data format and details how Microsoft ® Money uses ofc for online home banking and online bill payment features
|
|  Yüklə 0.88 Mb.
|
DTCLIENT and Money crash recovery behaviorOn each session with the server, Money will put the date and time of the call in the DTCLIENT element of the Signon request. If a communication error occurs during a session or if the connection encounters a “time-out,” Microsoft Money will enter crash recovery mode. While in this mode, a user will not be confident if their transactions were received by the server or not. While in crash recovery mode, Money will not permit the user to send new transactions to the server. The user will be prompted to call the server again and resend the previous set of transactions. Crash recovery mode persists between sessions with Money. When the user calls the server again, Money will send the exact same OFC request file to the server as it did on the last call to the server, when Money encountered a crash. This file will have the DTCLIENT value of the previous session. Money assumes that the server didn’t receive the transactions and sends them again. If the transactions were received and processed by the server, it is the server’s responsibility to prevent the transactions from processed twice. Server crash recovery behaviorTo guarantee that transactions are not processed multiple times, the server should store the OFC request and response files of the previous session. When the server receives a request file from Money, it should compare the value in the DTCLIENT element of the Signon request to the DTCLIENT element of the last request file. If they are equal, the server should assume Money is calling in crash recovery and the server should not process the transactions in the request file and send the response file from the previous session back to Money. If the DTCLIENT values are not equal, the server should process the transactions and send a new response file back to Money.
Algorithm to follow:If (DTCLIENT in the current Signon request == DTCLIENT in the previous Signon request) Don’t process the transactions in the request Send the previous response file to Money Else
Process the transactions in the request Using the SESSKEY element to track sessionsNote: This section describes optional functionality for a server. Money identifies each session with the server using the SESSKEY element in the OFC Signon record. The SESSKEY should be a value that uniquely identifies each user’s session between client and server. A bank may want to make sure a user is calling their server in sequence by tracking SESSKEY values. If the user calls the server with an unexpected SESSKEY value, the bank can consider this to be an error and deny a user access to the server. On the first call to an OFC server, Money will send a SESSKEY of zero (0) in the Signon request record. The server will process this request and send a Signon response back to Money. The Signon response from the server should include a SESSKEY value that will be sent in the next Signon request sent to the server. On subsequent calls to the server, the Signon request sent from Money will include the SESSKEY value that was returned in the last session’s Signon response. As an extra layer of security, the server can treat SESSKEY as session sequence numbers. The server should maintain the current and previous SESSKEY values. If the user is calling with a SESSKEY that is unexpected (not the current or previous SESSKEY,) the server can reject the transactions in the request file. The server should return a Signon response record with a STATUS of 103 (Bad SESSKEY.) Based on this STATUS code, Money will display an error message to the user asking them to call their bank. When the user calls their bank, it is expected that the bank will re-authenticate the user and then configure the server such that the next time the user connects, the server will process the transactions in the request file. Algorithm to follow if the server is tracking SESSKEYs:If (DTCLIENT in the current Signon request == DTCLIENT in the previous Signon request) Don’t process the transactions in the request Send the previous response file to Money Else
If SESSKEY in the request file is the expected SESSKEY Process the transactions in the request Else SESSKEY in the request file is not the expected SESSKEY and is not the previous SESSKEY Don’t process the transactions in the request Send just a Signon response with STATUS of 103 Notes:
Chapter 8
This chapter includes an introduction and some general notes about how Microsoft Money uses the OFC data format. The OFC data format is composed of a set of records, each designed to represent a particular type of transaction between Microsoft Money and a server. OFC is designed in a request-response model. OFC records come in pairs; each transaction includes a request and a response. The request transaction is designed to ask the server a question, the response will provide the answer. For example, one OFC transaction request asks the server for the latest balance of an account, and the response delivers the account balance to Microsoft Money.
Chapter overview
|