Użytkownik "MarekM" <m...@w...INTERIA.i-to.PL> napisał w wiadomości
news:cl3ivd$16l$1@atlantis.news.tpi.pl...
> TomekD dnia 2004-10-19 19:15 napisał(a) co następuje:
>
> Zlecenia ponawiane są również w BGŻ Integrum (system on-line) oraz
> Pekao24. W tym pierwszym podczas "selekcji" przelewów przed każdą sesją
> Elixir (mniej więcej godzinę-dwie przed wysłaniem danych), a dodatkowo 5
> minut przed ostatnią sesją.
[...]
> Ale należy jeszcze zdefiniować, co to jest system on-line, a co off-line
> - myślę że to tylko "grupowa" umowa. Dla mnie system on-line to taki
> system, w którym skutki wszystkich operacji "widziane" są we wszystkich
> kanałach dostępu (wliczając w to karty). Warunek ten spełnia zarówno
> Pekao, jak i BGŻ. A jak system działa wewnątrz, to już inna rzecz.
> "Onlajnowość" nie determinuje sposobu selekcji przelewów do wysłania.
> Niezależnie od tego, czy system "pobiera" dane o oczekujących przelewach
> z podystemu obsługującego kanał WWW tuż przed wysłaniem przelewu, czy
> też te dane siedzą w systemie od razu po ich wklepaniu na stronie, to i
> tak trzeba sprawdzić, czy jest wystarczające saldo.

Masz rację, zależy jak zdefiniować co rozumiemy jako system on-line.
Nie do końca zgodziłbym się z tobą że nie ma znaczenia jak 'system działa
wewnątrz', wydaje mi się to najbardziej istotne.
Dostęp przez WWW, telefon czy w jakikolwiek inny sposób to tylko inny
interfejs (frontend) do komunikacji z tym samym systemem (backend).
Jeżeli sam system (backend) jest w stanie realizować na bieżąco żądania
nadchodzące z różnych źródeł (frontend) to mamy system on-line.
Jeżeli natomiast zlecenia z różnych źródeł (frontend) zbierane są w kolejce
która tylko to co jakiś czas jest przetwarzana czy przesyłana do systemu
(backend) mamy system off-line.
Oczywiście nie da się zastosować takiego toku rozumowania do przelewów
zewnętrznych które nie mogą być wykonane w dowolnej chwili.
Czyli dla mnie system np. mBanku jest system on-line a VW off-line - nie ma
statusu 'w trakcie zakładania' - czyli -> czekam na obsługę przez system
backend...

TomekD

do góry

TomekD napisał(a):
> Masz rację, zależy jak zdefiniować co rozumiemy jako system on-line.
> Nie do końca zgodziłbym się z tobą że nie ma znaczenia jak 'system działa
> wewnątrz', wydaje mi się to najbardziej istotne.

Nie no, jasne - to jest bardzo istotne, gdyż to determinuje, czy próby
wysłania przelewu kolejną sesją są ponawiane, czy nie, ale wydaje mi
się, że ta cecha nie jest powiązana z off/on-lineowością. Wszystko
zależy od tego, jak system potraktuje brak środków do wykonania
zlecenia. Zauważ, że w systemie off-line też kiedyś takie zlecenie musi
mieć ustawiony status na nieaktywny (bo dziwnie wyglądałby "przelew
przyszły" z wsteczną datą na liście oczekujących, nieprawdaż?). Zmierzam
do tego, że tak naprawdę to jest odrębna cecha samego systemu, a nie
sposobu jego działania (w sensie off/on-line). BYĆ MOŻE w systemie
off-line jest to łatwiejsze do zaimplementowania (bo algorytm może być
taki: z systemów front-end zbierane są dane o zleceniach do wykonania,
jak się uda wykonać - to zlecenie dostaje status "zrealizowane", a w
"przetwarzaniu nocnym" wszystkie zlecenia z datą bieżącą (lub
wcześniejszą) dostają status "nieaktywne/niezrealizowane").

> Dostęp przez WWW, telefon czy w jakikolwiek inny sposób to tylko inny
> interfejs (frontend) do komunikacji z tym samym systemem (backend).
> Jeżeli sam system (backend) jest w stanie realizować na bieżąco żądania
> nadchodzące z różnych źródeł (frontend) to mamy system on-line.
> Jeżeli natomiast zlecenia z różnych źródeł (frontend) zbierane są w kolejce
> która tylko to co jakiś czas jest przetwarzana czy przesyłana do systemu
> (backend) mamy system off-line.

OK - myślę, że to dobra definicja (bardziej precyzyjna i techniczna od
mojej). Zauważ jednak, że ten "jakiś czas" może być baaardzo krótki i z
off-line'a się robi niemalże-on-line ;-)

> Oczywiście nie da się zastosować takiego toku rozumowania do przelewów
> zewnętrznych które nie mogą być wykonane w dowolnej chwili.

No właśnie: przelewy wychodzące i tak stoją w jakiejś kolejce, a czy
1. taka kolejka powstaje na bieżąco w systemie backend (on-line),
2. czy uzupełniana jest co jakiś czas (w trakcie "synchronizacji"
backend<->frontend),
3. czy też tworzona jest w systemie backend tuż przed sesją na podstawie
danych zgromadzonych w systemach frontend (i tylko wtedy),
to nie ma chyba nic wspólnego z tym, czy zlecenie z kolejki w momencie
braku środków zostanie wyrzucone, czy dostanie kolejną szansę.
Czyli nie jest ważny sposób wejścia do kolejki zleceń, tylko sposób jej
opuszczenia. A tu już różnice pomiędzy systemem on-line a off-line są
niewielkie: w pierwszym przypadku będzie wiadomo "od razu", że się nie
udało, w drugim może być co najwyżej jakieś opóźnienie z aktualizacją
statusu.

Właściwie to miałem na myśli :-)

--
Marek

do góry

Radoslaw P. dnia 2004-10-19 20:32 napisał(a) co następuje:

>>>Czyli co jakiś czas uruchamiany jest proces sprawdzający oczekujące do
>>>realizacji zlecenia i weryfikujący warunki wykonania.
>>Tak może być również w systemie on-line :-)
> Właśnie nie. To jest ta różnica pomiędzy on-, a off-line. :)

A właśnie że tak ;-)

Tu muszę wyjaśnić: nie pisałem o sposobie, w jaki przelewy trafiają do
realizacji, tylko o sposobie ich REALIZOWANIA.

W przypadku funkcjonalności przelewów zewnętrznych MUSI być wykonany
proces sprawdzenia warunków wykonania (odpowiedni stan konta) tuż przed
zdjęciem kwoty z konta (niekoniecznie jest to odrębny proces systemowy
sensu stricte rzecz jasna - nie to mam na myśli). Przelewy zewnętrzne
nie są wykonywane on-line, stąd funkcjonalność ta mało zależy od
"onlajnowości" systemu. Tak jak napisałem w jednym z poprzednich postów:
ważne jest, co się dzieje z przelewem PO jego niewykonaniu, a nie jak
trafia do kolejki przelewów PRZED realizacją.

--
Marek

do góry

Użytkownik "MarekM" <m...@w...interia.i-to.pl> napisał w wiadomości
news:cl40eh$m6s$1@srv.cyf-kr.edu.pl...
>
> Nie no, jasne - to jest bardzo istotne, gdyż to determinuje, czy próby
> wysłania przelewu kolejną sesją są ponawiane, czy nie, ale wydaje mi
> się, że ta cecha nie jest powiązana z off/on-lineowością. Wszystko
> zależy od tego, jak system potraktuje brak środków do wykonania
> zlecenia. Zauważ, że w systemie off-line też kiedyś takie zlecenie musi
> mieć ustawiony status na nieaktywny (bo dziwnie wyglądałby "przelew
> przyszły" z wsteczną datą na liście oczekujących, nieprawdaż?). Zmierzam
> do tego, że tak naprawdę to jest odrębna cecha samego systemu, a nie
> sposobu jego działania (w sensie off/on-line). BYĆ MOŻE w systemie
> off-line jest to łatwiejsze do zaimplementowania (bo algorytm może być
> taki: z systemów front-end zbierane są dane o zleceniach do wykonania,
> jak się uda wykonać - to zlecenie dostaje status "zrealizowane", a w
> "przetwarzaniu nocnym" wszystkie zlecenia z datą bieżącą (lub
> wcześniejszą) dostają status "nieaktywne/niezrealizowane").
[..]
> OK - myślę, że to dobra definicja (bardziej precyzyjna i techniczna od
> mojej). Zauważ jednak, że ten "jakiś czas" może być baaardzo krótki i z
> off-line'a się robi niemalże-on-line ;-)
[...]
> No właśnie: przelewy wychodzące i tak stoją w jakiejś kolejce, a czy
> 1. taka kolejka powstaje na bieżąco w systemie backend (on-line),
> 2. czy uzupełniana jest co jakiś czas (w trakcie "synchronizacji"
> backend<->frontend),
> 3. czy też tworzona jest w systemie backend tuż przed sesją na podstawie
> danych zgromadzonych w systemach frontend (i tylko wtedy),
> to nie ma chyba nic wspólnego z tym, czy zlecenie z kolejki w momencie
> braku środków zostanie wyrzucone, czy dostanie kolejną szansę.
> Czyli nie jest ważny sposób wejścia do kolejki zleceń, tylko sposób jej
> opuszczenia. A tu już różnice pomiędzy systemem on-line a off-line są
> niewielkie: w pierwszym przypadku będzie wiadomo "od razu", że się nie
> udało, w drugim może być co najwyżej jakieś opóźnienie z aktualizacją
> statusu.
>
> Właściwie to miałem na myśli :-)

Marku, dla jasności trzeba pewnie rozdzielić operacje wewnątrz banku i te
realizowane na zewnątrz.

W operacjach wewnętrznych (przelewy wewnętrzne, lokaty etc):
Jeżeli jesteś na stronie banku (frontend) )i wykonane przez ciebie operacje
natychmiast mają odzwierciedlenie w systemie banku (backend) to jest to
system on-line.
Jeżeli system transakcyjny jest obciążony to ty też czekasz dłużej niż
zwykle na potwierdzenie realizacji u siebie na ekranie.

W operacjach zewnętrznych (przelewy zewnętrzne):
System on-line niewiele różni się od systemu off-line.
Nawet w systemie on-line przelewy zewnętrzne funkcjonują na zasadzie
off-line (bo sesje ELIXIR mają ustalone godziny) i nie da się tego zrobić
inaczej.
Co zaś do np. prób powtarzania zleceń odrzuconych ze względu na brak środków
tak jak piszesz łatwiej jest to zrobić w systemie off-line, bo jest to 'przy
okazji'...
Pisałeś że w BGŻ czy Pekao24 (nie znam, znałem i do dziś tęsknię za
Telepeako24) system pracuje on-line. Jeżeli więc przelewy wewnętrzne między
rachunkami działają tam on-line to raczej nikt nie podejmie się zbudowania
systemu obsługującymi na 100% sytuacje powtarzania zleceń który będzie tak
naprawdę działał naprawdę 7dni/24godziny.
Ryzyko jest takie że kiedyś znajdzie się np. dociekliwy czytelnik
pl.biznes.banki :-) który potem napisze że nie działa a nikt nie ostrzegał.
Dlaczego ? No bo co się stanie gdy mamy:
- zlecenie przelewu wewnętrznego z datą przyszłą na 01-04-2004
- po północy z 31-03-2004/01-04-2004 brak środków na realizację
- o 23:59:55 dnia 01-04-2004 na rachunek wpływają środki z innego rachunku w
banku
Biedny projektant systemu musiałby w takiej sytuacji uwzględnić po każdej
operacji sprawdzanie czy aby nie ma zleceń oczekujących które w najbliższych
5 sekundach powinny zostać zrealizowane.
Co gorsza, na rachunku docelowym mogłaby pojawić się identyczna sytuacja o
23:59:59 :-)
Wiem że przykład mocno naciągany, ale w dobrym projekcie projektuje się na
najgorszy przypadek. Nie mówiąc już o tym że obciążenie systemu
koniecznością przeprowadzania dodatkowych kontroli (czy trzeba zrealizować
zaległe zlecenie) które w ułamku procentów doprowadzą do dokonania operacji
jest po prostu nieefektywny.

Wydaje mi się że systemy on-line są droższe na starcie, ale łatwiejsze w
utrzymaniu i rozwoju. Trudniej jednak jednak wprowadzać zmiany (stąd taka
ilość przerw konserwacyjnych w MBanku).
Systemu off-line łatwiej i taniej na początku rozwijać ale administrować
nimi to koszmar (stąd tak mało przerw konserwacyjnych w VW i dość sporo
wpadek typu coś nie przeszło albo wykonało się 2x). Ponadto istnieje poziom
krytyczny rozwoju systemu off-line ponad którym nie da się dalej go rozwijać
bez pogorszenia niezawodności i dostępności.

TomekD

do góry

Wed, 20 Oct 2004 16:29:13 +0200, w <cl5som$hiu$1@atlantis.news.tpi.pl>, MarekM
<m...@w...INTERIA.i-to.PL> napisał(-a):

> Radoslaw P. dnia 2004-10-19 20:32 napisał(a) co następuje:
>
> >>>Czyli co jakiś czas uruchamiany jest proces sprawdzający oczekujące do
> >>>realizacji zlecenia i weryfikujący warunki wykonania.
> >>Tak może być również w systemie on-line :-)
> > Właśnie nie. To jest ta różnica pomiędzy on-, a off-line. :)
>
> A właśnie że tak ;-)
>
> Tu muszę wyjaśnić: nie pisałem o sposobie, w jaki przelewy trafiają do
> realizacji, tylko o sposobie ich REALIZOWANIA.

A to nie szkodzi. Jak on-line, to weryfikacja również powinna być on-line.
Skoro jest choćby jedna rzecz off-line, to system jest off-linowy i tylko
kwestią umowy pozostaje ustalenie na ile jest off-line.

> W przypadku funkcjonalności przelewów zewnętrznych MUSI być wykonany
> proces sprawdzenia warunków wykonania (odpowiedni stan konta) tuż przed
> zdjęciem kwoty z konta (niekoniecznie jest to odrębny proces systemowy
> sensu stricte rzecz jasna - nie to mam na myśli). Przelewy zewnętrzne
> nie są wykonywane on-line, stąd funkcjonalność ta mało zależy od
> "onlajnowości" systemu. Tak jak napisałem w jednym z poprzednich postów:
> ważne jest, co się dzieje z przelewem PO jego niewykonaniu, a nie jak
> trafia do kolejki przelewów PRZED realizacją.

A to jeszcze zależy co jest sprawdzane off-line. Jak stan konta to OK, tutaj
system VWB jest wyraźnie lepszy od mBankowego onlajnu. Jak nr konta, to już nie
:)
Poza tym w VWB stan konta jest chyba off-liinowo sprawdzany również przy
przelewach wewnętrznych. :)

do góry

> Poza tym w VWB stan konta jest chyba off-liinowo sprawdzany również przy
> przelewach wewnętrznych. :)

A skad ta wiedza ?

VG

do góry

Wed, 20 Oct 2004 18:47:19 +0200, w <cl64tc$fkl$1@atlantis.news.tpi.pl>, Van
Gogush <g...@p...onet.pl> napisał(-a):

> > Poza tym w VWB stan konta jest chyba off-liinowo sprawdzany również przy
> > przelewach wewnętrznych. :)
>
> A skad ta wiedza ?

Przypuszczenie.

do góry

Radoslaw P. napisał(a):
>>Tu muszę wyjaśnić: nie pisałem o sposobie, w jaki przelewy trafiają do
>>realizacji, tylko o sposobie ich REALIZOWANIA.
> A to nie szkodzi. Jak on-line, to weryfikacja również powinna być on-line.
> Skoro jest choćby jedna rzecz off-line, to system jest off-linowy i tylko
> kwestią umowy pozostaje ustalenie na ile jest off-line.

Ale nie da się zrobić weryfikacji on-line, bo przelewy zewnętrzne nie
działają on-line :-) Więc rozumując w ten sposób żaden system bankowy
nie jest on-lineowy ;-)

Wyobraź sobie dwa systemy:

1. Zlecasz przelew z datą bieżącą - kwota od razu zdejmowana jest z
konta (mimo że jeszcze przelew nie wyszedł z banku), wychodzi najbliższą
sesją (za x godzin). Wówczas masz weryfikację salda on-line, ale
pieniądze znikają z konta szybciej, niżby mogły (tak działa Pekao24 i
Integrum BGŻ - i nie przeszkadza mi to nazywać ich systemy on-lineowymi,
bo w każdym kanale dostępu widoczne jest zawsze to samo saldo,
aktualizowane na bieżąco).

2. Zlecasz przelew z datą bieżącą - wędruje do przelewów oczekujących na
sesję Elixir. Fakt, trzeba sprawdzić, czy saldo jest odpowiednie, ale
przecież w czasie od zlecenia tego przelewu do rozpoczęcia sesji kwota
może zostać pobrana z konta w inny sposób (choćby wypłata gotówkowa, czy
rozliczenie transakcji karcianej, której blokada wygasła wcześniej).
Wówczas tuż przed wysłaniem konieczne jest ponowne sprawdzenie salda. No
chyba że zakładana jest blokada na ten "czas oczekiwania". Jak to jest w
mBanku? (nie pamiętam).

> A to jeszcze zależy co jest sprawdzane off-line. Jak stan konta to OK, tutaj
> system VWB jest wyraźnie lepszy od mBankowego onlajnu. Jak nr konta, to już nie
> :)

Hm nie wiem, ale nie podejrzewam projektantów systemów bankowych o taką
ignorancję. Chociaż...

> Poza tym w VWB stan konta jest chyba off-liinowo sprawdzany również przy
> przelewach wewnętrznych. :)

A to już bardzo niemiła cecha...

--
Marek

do góry

TomekD napisał(a):

> Marku, dla jasności trzeba pewnie rozdzielić operacje wewnątrz banku i te
> realizowane na zewnątrz.

Jasne.

> W operacjach wewnętrznych (przelewy wewnętrzne, lokaty etc):
> Jeżeli jesteś na stronie banku (frontend) )i wykonane przez ciebie operacje
> natychmiast mają odzwierciedlenie w systemie banku (backend) to jest to
> system on-line.
> Jeżeli system transakcyjny jest obciążony to ty też czekasz dłużej niż
> zwykle na potwierdzenie realizacji u siebie na ekranie.

Zgadza się.

> Pisałeś że w BGŻ czy Pekao24 (nie znam, znałem i do dziś tęsknię za
> Telepeako24) system pracuje on-line.

Według mojej definicji ;-)

> Jeżeli więc przelewy wewnętrzne między
> rachunkami działają tam on-line to raczej nikt nie podejmie się zbudowania
> systemu obsługującymi na 100% sytuacje powtarzania zleceń który będzie tak
> naprawdę działał naprawdę 7dni/24godziny.

Bardzo ciekawy przykład podałeś. Cóż, jutro sprawdzę, jak to wygląda w
BGŻ ;-) Tam doskonale widać, co się działo, bo w szczegółach zlecenia są
komunikaty systemu o stanie operacji (czyli: zatwierdzenie / odrzucenie
i powód) z dokładną datą i godziną. A mam dwa rachunki w Integrum, więc
nie zaszkodzi potestować.

> Wydaje mi się że systemy on-line są droższe na starcie, ale łatwiejsze w
> utrzymaniu i rozwoju. Trudniej jednak jednak wprowadzać zmiany (stąd taka
> ilość przerw konserwacyjnych w MBanku).

Racja.

> Systemu off-line łatwiej i taniej na początku rozwijać ale administrować
> nimi to koszmar (stąd tak mało przerw konserwacyjnych w VW i dość sporo
> wpadek typu coś nie przeszło albo wykonało się 2x). Ponadto istnieje poziom
> krytyczny rozwoju systemu off-line ponad którym nie da się dalej go rozwijać
> bez pogorszenia niezawodności i dostępności.

Co doskonale widać na przykładzie BePeHahaha, prawda Bartol? ;-)

--
Marek

do góry

MarekM dnia 2004-10-20 20:52 napisał(a) co następuje:

> Bardzo ciekawy przykład podałeś. Cóż, jutro sprawdzę, jak to wygląda w
> BGŻ ;-) Tam doskonale widać, co się działo, bo w szczegółach zlecenia są
> komunikaty systemu o stanie operacji (czyli: zatwierdzenie / odrzucenie
> i powód) z dokładną datą i godziną. A mam dwa rachunki w Integrum, więc
> nie zaszkodzi potestować.

No i mam odpowiedź: wygląda na to, że w Integrum przelewy wewnętrzne
zlecone z datą przyszłą oraz zlecenia stałe traktowane są dokładnie tak
samo, jak przelewy zewnętrzne (czyli przesyłane w godzinach sesji
Elixirowych. Być może przed końcem dnia jest jeszcze jedna "sesja"
takich przelewów wewnętrznych - sprawdzę.

Ale przelewy wewnętrzne z datą bieżącą działają on-line.

--
Marek

do góry