Business-OCV
view release on metacpan or search on metacpan
# There is one OCV method provided for each message type. Each message
# method constructs and sends an appropriate OCV message and, if 'polled
# mode' is off (i.e. blocking mode, the default), will wait to receive a
# response from the server. It will then either timeout and return an error,
# or return the server response in the form of an array or OCV::Message
# object. In polled mode it simply returns an empty message (empty list /
# undef).
#
# Note that due to the nature of the OCV protocol, if a timeout occurs
# (or any error, for that matter) the message exchange sequence will likely
# be out of synchronisation. The server connection should be terminated and
# reestablished, a reset() method is provided to do so.
#
# Error Conditions
#
# Generally, all methods return a true value/list on success, or
# undef/empty list on failure. An error message should be in $@.
# If a 'warning' is raised, a successful return value is given with
# $@ set to the warning message. i.e. if $@ is set, the result warrants
# closer inspection.
# e.g.
# defined($m);
# }
# or do # catch
# {
# print "Error: $@\n";
# undef;
# };
#
# Any number of communications failures may occur between this client and
# the OCV server. Some of these error conditions could cause the command-
# response sequence to become missynchronised, thus it is advised that the
# connection be closed and re-opened upon error. A flush() method is
# provided if you wish to attempt to "manually" resynchronise. A
# reset() method is also provided: it closes the OCV connection,
# reopens the log file/s, and reopens the OCV connection. This should
# reset things to a virgin state. A reset() may also be in order in
# response to a HUP signal.
#
#
# NOTES/CLARIFICATIONS ON THE OCV SERVER DOCUMENTATION
#
# - Pre-authorisations and Completions
# These transactions are handled completely by the bank - that is, the
# OCV DEVELOPMENT SERVER BUGS
#
# The OCV 'Development Server' supplied by Ingenico for testing and
# development purposes has a few bugs which mean it's not an entirely
# reliable means of testing your code. As of v.1.15, it:
# - often locks up and/or crashes with dud messages
# - does not respond well to polled requests. It 'locks' the account after
# serving some polled requests (i.e. subsequent transactions on the
# account return SERVER BUSY or RECORD NOT FOUND). In addition, on
# subsequent connections it erroneously sends a response to the polled
# request which mis-synchronises the rest of the communications.
# - does not return full details for status requests (for example, it omits
# the settlement date, card info, merchant + terminal IDs)
#
# OCV LIVE SERVER BUGS
#
# Unfortunately the Ingenico 'live' server (v2.08) has also shown problems,
# with one issue of a complete lockup after a totals requests (the NT registry
# had to be edited to restore service). Additionally, the server is found to
# issue unsolicted 'logon responses' around once per week. Ingenico have
# advised this is an "undocumented feature".
local $^W = 0; # ignore IO::Socket warnings
$self->disconnect(@_) if (!$self->{'disconnected'} and
$self->{'io'} and $self->{'io'}->connected);
}
}
sub open { shift-> connect(@_); }
sub close { shift->disconnect(@_); }
sub flush
# try and resynchronise the connection by dumping all pending input
# - probably better to close and (re-)open (see reset method)
{
my $self = shift;
my $buf;
while ($self->{'sel'}->can_read(0) and $self->{'io'}->sysread($buf, 8192))
{
$self->logdebug("flush: discarding [$buf]");
}
"\000"; # true, but "silent" (mainly for the ocv command line util)
}
utilities/ocvtest view on Meta::CPAN
this test (unless you have all day :-)
EOM
print <<EOM if $polled;
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
NOTE: the test OCV server (at least v1.15) does not respond well to polled
requests. It 'locks' the account after serving some polled requests (i.e.
subsequent transactions on the account return SERVER BUSY or RECORD NOT FOUND).
In addition, on subsequent connections it erroneously sends a response to the
polled request which missynchronises the rest of the communications.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
EOM
# the OCV always appends to its logs, so manually truncate them if required
# - create/truncate the log files now, so as to allow them to be tailed
# before starting the test
map { my $f = LOGDIR . $_; open (FH, TRUNCATE ? ">$f" : ">>$f") }
TXNLOG, DEBUGLOG;
close FH;
utilities/totals view on Meta::CPAN
# Usage
#
# Generally:
# totals [options] <accountnum> <date> [<transaction log> ...]
# Where <date> may be an integer offset from today.
#
# There is currently one option allowed, plus an '--' option terminator:
# --force force - don't exit on errors
# -- stop looking for options
#
# There are at least three asynchronous processes affecting the transaction
# logs:
# - the bank cuts over to a new settlement date at some random time of day
# - the transaction logs are rotated at some random time of day
# - live transactions are initiated and completed at random times, and
# with random and potentially large durations (e.g. if manual intervention
# is required to complete/query a transaction).
# To avoid such timing dependancies, it is advised that this filter be run
# over a set of 'archived' logs, spanning at least a day either side of the
# desired date (or more, if errors have occured).
#
( run in 0.246 second using v1.01-cache-2.11-cpan-0d8aa00de5b )