non-telecom in erlang

DANIESC SCHUTTE DANIESC.SCHUTTE@REDACTED
Tue Feb 4 09:29:17 CET 2003


Greetings all, Mickael

Initial answers:  (if it is too short - or you want more information - please let me know)

Firstly:

Teba Bank services the lower end of the South African market, the system is designed for maximum speed (our target market is 85% of the South African market) and THE LOWEST POSSIBLE transaction cost.  The bank has been in existence for 24 years and has been paying the mine worker salaries of a lot of mines in South Africa and have only become a formal bank 2 years ago.

The FDFC - situated in the UK,  must also be mentioned (Financial Deepening Challenge Fund) as they provided a grant to this project.

Ok the nitty gritty technical stuff:

The system requirement is a 100% uptime, 24x365.
The biggest benefit is real time ABC (activity based costing).  Meaning - if a ussd message was sent with a transaction for processing and the transaction concludes about 0.4 seconds later ( :) ) all costs have been allocated to all the relevant cost centres/ accounts.  Meaning - the funds to pay for the USSD has been paid to the GSM operator, the tax has been provisioned for, the transaction fees are taken and allocated to the relevant cost centres.  Meaning - if I want a balance (via USSD from my phone - on what I need to pay over to the GSM operator - I get an up to the second amount). 

1.  Choosing Erlang - (the why?)  not necessarily in order.

a)  All the standard spiel you get about it.  (Robust, realtime-code updates, and all the weird and wonderfull stuff you get in the manuals :) ).
b)  Multi-platform  (We run Solaris i386 / Sparc - Windows was considered but rejected at some point - and linux might be a future option)
c)  OTP.  What is the difference in ESSENCE between switching a telephone call, and switching money. (Erlang in our mind was essentially a SWITCHING language - but has grown to a lot more).
d)  The learning curve was not as steep as anticipated.
e)  Code size is a lot smaller and development a lot faster.
f)  BRILLIANT SUPPORT - with the guys responding to some of our queries in less than 15 minutes on an opensource project - that is why the budget this year includes licensing fees :).
g)  Interoperability with other languages ( C ).
h)  The choice felt right.
i)  Was there ever another choice :)  - on the table was C, Kylix, Delphi, Java and Erlang.

2.  Interfaces to the external world

We have a module called ConnectionManager that handles all external and internal connections to the processing "engine".  Writing a new interface - currently about 2 - 4 days before testing.  (ISO8583 flavours - 1 day :) ).

XML is a change request :) 

Physical: USSD over TCP/IP, TCP/IP and X-COM (we gotta talk to a mainframe somewhere :) )

a)  Point of Sale Banking (USSD Phase I communications) Erlang with a C api handling the requests.  (This is because we service the South African rural market - and there is NO FORMAL COMMUNICATIONS mechanisms - except GSM.
b)  Bankserve (central banking switch for SA) - an ISO8583 Postbridge interface (Postilion) over a tcp/ip link.  Both as an issuer as well as an acquirer.
c)  SA Debit Card Switch (same as above)
d)  Mastercard ISO8583 interface specification (Issuer and acquirer)
e)  ACB  (Batch based transactions).
f)  Front-ends handled by the current banking system - and information passed via tcp/ip to us.
g)  Customer Relationship Management interface - via tcp/ip
h)  External General Ledger interface - via tcp/ip
i)  External Hardware Security Module communications.  (We used crypto initially - but the requirements are for a hardware security module)  CRYPTO works fine (if you add some stuff :) )

Hardware: We are running triple failover (3 separate sites - simultaneously processing all transactions) with an additional backup / disaster recovery site.
Each site:  1 x SUN SPARC Database Server (currently running Sybase 12.5)  (we are looking at MNesia for some of our next roll-outs)
                  2 x Compaq DL360 Application Servers (Doing the physical transaction processing).
Solaris 8 O/S
No special hardware, no special software.


3.  Distribution

Yes, we have implemented distribution both for processing power as well as fail over - see above.  We are looking at moving into the load balancing area now.


4.  User Interface

Front ends are the only windows machines so far.

Since it is a banking system - we have isolated the user interfaces into delphi front ends - that communicate via tcp/ip messages to erlang modules that verify the security and then process the relevant transactions.

We are looking at converting this to Java or even Erlang - but for now that was a bit much :).

5. Non Erlang Code
 Languages: Delphi 6, C.

 The user interface, and the API calls to the Sybase database, and the API calls the the Sema USSD server is THE ONLY code not written in erlang.
  We have module called DBI (database interface) that handles the writing to the database through the api and verifies that all went well and connect_ussd which handles the sema api calls.
  The user interface also converses with the erlang modules.


Any suggestions or queries are more than welcome. 
Marketing spiel:
   If you need a billing / banking / POS / transacting  system - talk to us - as the idea is to distribute this type of system (after successful conclusion of our pilot) - and we work in rands :) which is worth almost NOTHING :) hehehehe


Regards
Danie Schutte





Danie Schutte
Phone: +27 - 11 - 203 - 1613
Mobile: 084-468-3138
e-Mail: Daniesc@REDACTED

>>> Mickael Remond <mickael.remond@REDACTED> 02/03/03 11:53PM >>>
* DANIESC SCHUTTE <DANIESC.SCHUTTE@REDACTED> [2003-02-03 11:55:30 +0200]:

> Hello all,
> 
> What kind of information would be required.  I've got permission from
> the CEO of Teba Bank (South Africa) to disclose "relevant"
> information.  We would like to let the Erlang community know about
> this - (we've been approached for an adaptation for a gsm cellular
> billing system integration - and would like to have input / advice on
> this as well in order to futher the solutions possibilities.)

One question is: Why did you choose Erlang for this development ? What
was the most important elements that lead you to choose Erlang.

What are the needed interface to the external world ? Did you need to
create some link with special software running on dedicated hardware ?

Do you use distribution ? What is the user interface for the system ? Do
you have piece of the software that you choose not to write in Erlang ?

Thank you in advance for your feedback :-)

-- 
Mickaël Rémond
#####################################################################################
The information contained in this message and or attachments is intended
only for the person or entity to which it is addressed and may contain
confidential and/or privileged material.  Any review, retransmission,
dissemination or other use of, or taking of any action in reliance upon,
this information by persons or entities other than the intended recipient
is prohibited. If you received this in error, please contact the sender and
delete the material from any system and destroy and copies.
#####################################################################################



More information about the erlang-questions mailing list