Volume 3, Issue 2

Level Four and Ascert Win Recognition for Innovation

#

The implementation of a combined end-to-end ATM testing solution at Barclays Bank from Level Four, the provider of open standards-based ATM testing software, and Ascert, has been selected by Finextra to feature in its first 'Innovation Showcase'. Finextra, the independent newswire and information source for the financial technology community, sought to highlight some of the most interesting financial technology developments over the past 12 months and chose the project to feature in its 'Retail Channel Delivery and Management' category.

Finextra summarized the project in its showcase feature: "Barclays has deployed an end-to-end automated testing solution from Level Four and Ascert to support the biggest ATM refresh project by a UK bank in over a decade. The bank is moving away from proprietary ATM software and migrating more than 3,000 ATMs to an open standards environment, implementing Windows and packaged software such as BASE24 and ProCash."

"The project is also unique in the extent of its collaboration between the bank and its technology partners, Level Four and Ascert. Together, they have developed an advanced strategy for the rapid testing of the entire end-to-end transaction process, taking automated ATM testing to a completely new level. The testing environment went into pilot stage in September 2008. To cope with this complex environment, Barclays has implemented BRIDGE:test from Level Four to automate the testing of the entire ATM stack and VersaTest from Ascert for message and host testing."

Elton Cane, strategy director at Finextra, commented: "What were we looking for? Newness, uniqueness and impact; clever ways of solving a problem; and projects at the leading edge of new industry trends." Commenting on the Barclays project, Cane added: "This kind of behind-the-scenes work, as well as being innovative in its scale and approach, will make it much easier for the bank to deliver new services via the ATM channel and be seen as innovative by its customers."

Martin Macmillan, Business Development Director at Level Four, added: "This is a real endorsement of the value that innovation can bring to banks' ATM networks. The complexities of open standards environments call for an end-to-end approach to ATM testing. Through automation, banks can carry out more extensive tests with greater frequency, enabling them to accommodate regular product upgrades and maximize the value of their ATM networks."

Mike Wainwright, Business Development Director in Ascert's London office, said: "The success of this project really validates the need for a rethink in end-to-end ATM testing to achieve the best possible results. We look forward to building on the successes already achieved by working collaboratively with Level Four and replicating that success with our other customers in the future."

Read the Finextra article.

---

Questions & Answers

 Q:  We are in the process of converting a VersaTest script running on our HP NonStop system to use TCP/IP communications instead of X.25.  After adding the TCP/IP construct and modifying the SESSIONS declaration to reference it, we're getting the error:

"Logical session identifier INTERFACE has not been assigned to a physical session...script not loaded"  

Our TCP/IP and SESSIONS declarations are show below; what's the problem?

TCP_IP mysock
    polarity client
    remote_address ENV_PARAM_GET("requester.remote.address","","127.0.0.1")
    remote_port ENV_PARAM_GET("requester.port.number","","6061")
    message length at byte 0 field is decimal for 4
;

SESSIONS ( INTERFACE ( TCP_IP mysock))
A: VersaTest/NSK allows the use of logical session identifiers in the SESSIONS declaration, in your SESSIONS declaration, this identifier is "INTERFACE". Specifying a session identifier in this way allows scripts to be written in a session independent manner and allows the assignment of the physical client session name to be deferred until runtime (facilitating the re-use of scripts without recompilation). The physical session name must then be specified at runtime using a file assignment. So, in your case, you simply need to set the assignment in your TACL environment before starting the script e.g "ASSIGN INTERFACE,$ztc0.#term1".

Q: We need to process messages that include a variable number of occurrences of a structure at the end of a message.  The occurrences are separated by delimiters with a value of HEX "1C" as shown in the following message structure. Unfortunately, the last occurrence of the sub-structure is followed by HEX "03" instead of HEX "1C", which causes the message processing to fail.  How can I deal with this situation?

+STRUCT resp_msg;
 begin
   field is int16             msg_len;
   field is ascii for 4   device_type;               
   field is ascii for 2   msg_num;                             
   field is ascii for 5   store_num;                             
   field is ascii for 2   register_num;                           
   field is ascii for 4   txn_num;                               
   field is ascii for 3   cashier_id;                             
   field is ascii for 1   request_type;                         
   field is ascii for 19  account_num;                           
   field is ascii for 1   originator_ind;                       
   field is ascii for 12  tran_date_time;                         
   field is ascii for 3   resp_code;                             
   string                 seperator;       
   STRUCT resp_fid OCCURS UPTO 15 UNTIL EOM;                       
   begin                                                         
      field is ascii for 1         fid;                                     
      field is ascii until {%H1C}  fid_data;                         
   end;                                                           
 end;
A: Sometimes message formats just aren't what you'd like and a bit of pre or post processing is required to deal with them.  As you point out, the last occurrence of fid_data won't be properly identified because it ends in HEX "03" rather than HEX "1C" as specified in the data structure.  This is a fairly common scenario and the way we've always dealt with it is to check the last byte of an incoming message to see if it has a value of "03" and, if so, replace that value with "1C", which allows the message to be handled appropriately using the defined structure.  Generally, this activity is performed in the "INBOUND" construct and a corresponding activity is performed in the OUTBOUND construct to replace "1C" in the final byte with "03".

Q: My company has just purchased VersaTest Automator.  We will be using Ascert's SPDH driver for regression testing and I have been assigned the task of defining the regression test cases for our environment.  What training is available?
A: Ascert offers the "VersaTest Automator Test Case Development Training" class, which provides one week of hands-on instruction in all aspects of test case definition.  This instructor-lead class is generally provided at the customer site and can accommodate up to 8 students.  For additional information or to schedule training,contact
    
Have a question? Send us an email to support@ascert.com and ask the experts!