** Peter <p...@p...fm> wrote:

(Ciach SLA)

> To wiele wyjaśnia. Gdyby jednak przyjąć, że ten sms może być wysłany, ale
> niekoniecznie z takim czasem, jak 1-2h, tylko po prostu wysłany, to mamy dwie
> sytuacje:

Nie. Ale to nie rozumiemy się. W *normalnej* sytuacji SMS jest wysyłany od
Ciebie do bramki z prędkością jakieś 50 szt. na sekundę. Dalej bramka brokera
rozsyła do danych SMSC ale generalnie trwa to momentalnie (o ile odbiorca ma
włączony telefon, nie występuje np. świąteczne przeciążenie sieci GSM itd.).

O czym ja mówię to sytuacja, w której brokerowi pada datacenter i wyniku tego
Ty nie możesz nic wysłać przez jakiś czas.

> * sms dojdzie, kiedy będzie mógł; to oznacza, że może dojść nawet w ciągu
> kilku godzin (nie wiem czy też nawet nie w ciągu 24h, choć to chyba
> skrajność)

Ale to nie o to mi chodziło (chociaż de facto chodzi o fakt dojścia SMS) -
chodzi mi o to, że bramka dostawcy padła i jej nie ma.

> * beneficjent takiej usługi nie musi ponosić kosztów z tytułu utrzymania
> wysokich warunków SLA

No to nie ma uzasadnienia dla płacenia za SLA. Nie napisałeś nic o tym jaka to
usługa dlatego zwracam na to uwagę.

Np. są usługi w których Ty klientowi gwarantujesz, że co by się nie stało to
dostanie SMS w ciągu N jednostek czasu, a jak nie dostanie to Ty wypłacasz
odszkodowanie. Jeżeli klient sobie tego życzy to odpowiednio zapłaci. W takiej
sytuacji Ty z kolei wymagasz od brokera zbliżonych parametrów, aby było tak, że
jak Ty się nie wywiążesz z usługi to płacisz klientowi odszkodowanie z tego co
Ci broker wypłacił. :) Mniej więcej po to jest SLA.

(...)

> A z drugiej strony czy wysłany sms po n godzinach będzie nadal miał sens?
> Chodzi o to, że podaną wiadomość odczytam dawno w programie, po czym po paru
> godzinach dostanę wiadomość dokładnie taką samą, ale sms-em.

Od tego to jest ważność wiadomości SMS, którą respektuje SMSC operatora
komórkowego - i to jest kolejny (o ile Ci to potrzebny) parametr, który
chciałbyś przekazywać do brokera wywołując API.

> W takim przypadku kompromisem byłoby móc anulować wysłanie sms-a, zanim się
> go otrzyma. Np. kiedy wiadomość odczytam już w programie, to sms już nie jest
> mi potrzebny. A zatem mógłbym dokonać anulowanie wysyłki sms-a. Pytanie
> tylko czy to możliwe?

Ja się pogubiłem w tym co napisałeś. Generalnie przez brokera w prosty sposób
to się odbywa tak:

1. Wysyłasz przez API wywołanie wysłania SMS do brokera.
2. Broker przetwarza wywołanie i przesyła do właściwego SMSC (wcześniej jeszcze
odpytuje SMSC o przynależność numeru bo obecnie prefiks nie definiuje z jakiej
sieci jest numer).
3. SMSC odbiera wiadomość SMS, kolejkuje i dostarcza (bądź nie - abonent
niedostępny) wiadomość.

W między czasie broker może odpytywać SMSC operatora o status wiadomości
(odebrana, oczekuje, zły numer itd.), a Ty możesz odpytywać o to brokera.
Działanie asynchroniczne.

Co może pójść nie tak?
1. Połączenie do brokera nie jest dostępne - padła sieć.
2. Połączenie do brokera jest ale wysypał im się serwer/usługa i nie odpowiada.
3. Połączenie do brokera i usługi jest, ale oprogramowanie brokera zwariowało i
faktycznie nic nie wysyła.

I to samo powyższe na styku broker/operator. Do tego dodaj jeszcze odpytywanie
o status itd. :)

(...)

>> Czyli tylko wysyłać - bez interakcji i odbierania?

> Tak, ponieważ ten sms zawierać ma informację "tylko do odczytu".

Ale jedną wiadomość w ciągu N czasu czy może to będzie tak, że w ciągu
przewidywalnego czasu do odbiorcy wyślesz kilka wiadomości? Jeżeli tak to
pogadaj z brokerem o pakietach - duzi operatorzy już je obsługują. Chodzi mi o
to, że jeżeli wyjdzie Ci, że przy jednej "transakcji" w systemie statystycznie
wychodzi 2,3 wysłanych wiadomości SMS w ciągu np. doby to warto pomyśleć o
pakietach (to jest po prostu forma rozliczenia).

(...)

>> Rejestracja identyfikatora to jednorazowa opłata rzędu 1000zł - dostawca
>> musi przejść procedury w centrach SMSC każdej z sieci (!) aby zarejestrować
>> taki identyfikator. Kiedyś mając dostęp do SMSC dało się słać z dowolnym
>> identyfikatorem tekstowym ale stwarzało to podatność dla systemów np.
>> tokenów przy płatnościach itd.

>> (...)

> W takim razie mogę śmiało uznać, że wystarczy, jeśli to będzie z numeru.
> Jakiegokolwiek. To w zupełności wystarczy. Ten sms nie ma jakiejś krytycznej
> wartości, a ma być jedynie nośnikiem informacji, gdyby nie było się w tym
> momencie przy komputerze.

No ale to powinieneś napisać od razu. :)

(...)

>> Poza tym to też zależy od tego dla jakiej organizacji/instytucji
>> implementowany jest ten system. Np. u mnie jakby jakaś kontrola wewnętrzna
>> (a mogę liczyć, że będzie ich przynajmniej dwie prędzej czy później)
>> wykryłaby, że jakiś tam SMS nie został wysłany, został zafakturowany, a
>> umowa przewiduje karę umowną to by mnie ścigali, że działam na szkodę... :)

> No właśnie. Dlatego, jak podałem wyżej, można by zliczać po swojej stronie
> ilość wysłanych sms-ów i porównywać to z danymi od operatora. Pytanie tylko
> na ile operator w ogóle weźmie pod uwagę ilość podaną przez beneficjenta w
> przypadku reklamacji? Musiałby istnieć jakiś system weryfikacji danych.

Musisz po swojej stronie zapisywać wszystko co wysyłasz (log po prostu data, nr
odbiorcy, treść, identyfikator transakcji itd.), od dostawcy wymagaj, aby taki
sam log (tylko od swojej strony) przekazywał Ci w raporcie billingowym do
faktury. A potem przy rozliczeniu weryfikuj. Dodanie przekazywania unikatowego
(ten definiujesz Ty) identyfikatora aby się pojawiał w raporcie zwrotnym
ułatwia przetwarzanie takich danych no bo wiąże to co jest u Ciebie, z tym co
Ci liczy dostawca.

Przy czym kontrola jest dlatego, że każdy może się pomylić. Nie sądzę aby na
sensownych warunkach umowy dostawca miał motyw do tego aby robić drobne
przekręty w ten sposób. Po prostu chodzi o wykrywanie pomyłek, a dalsze
postępowanie to przecież zależy od zaufania i woli współpracy - najczęściej jak
dostawca się pomyli i stwierdzi to u siebie na podstawie Twojego raportu to do
jakiegoś kompromisu dojdziecie np. policzy Ci mniej za następny miesiąc.

(...)

>> I możesz sobie skorelować to co wysyłasz od siebie z tym co jest
>> billingowane u operatora - przecież bez tego nie jesteś w stanie weryfikować
>> czy wspomniane 1-2h jest realizowane prawda?

> O proszę. A parę linii wyżej właśnie o to się martwiłem, po czym widzę, że
> jednak jest możliwa weryfikacja kontroli działania usługi.

No tak. Tylko, że ja zupełnie nie mam doświadczenia z takimi masowymi bramkami.
To co my mamy to API było tworzone pod nasze wymagania i tam to precyzowaliśmy,
nie wiem jak jest u masowych (ale to logiczne jest aby była taka funkcjonalność
- zwróć na to uwagę).

> Pozostaje mi tylko pytanie czy można anulować wysyłkę sms-a, jeśli jeszcze go
> nie otrzymałem, a wiem np., że już go nie potrzebuję.

Szczerze mówiąc nie wiem. Anulować możesz tylko wiadomości oczekujące na
doręczenie. A wydaje mi się, że zaksięgują Ci płatność za wysyłkę bez względu
na to czy odbiorca miał włączony czy wyłączony telefon.

--
+ ' .-. .
, * ) )
http://kosmosik.net/ . . '-' . kK