Konrad Kosmowski pisze:
> ** 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.

W porządku. Powyższe jednak nie stanowi problemu, ponieważ wiadomość
wysłana sms-em nie jest krytyczna, tzn. nie musi być dostarczona w
określonym przedziale czasowym. Nie jestem pewien, czy dobrze się
rozumiemy, ale może trzeba więcej informacji.

>> * 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.

Wtedy powinienem mieć przynajmniej jakiś komunikat zwrotny. O ile jest
taka możliwość. Padnięcie usługi nie oznacza od razu brak kontaktu z
serwerem brokera. Chociaż nie mogę tego wykluczyć.

>> * 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ę.

Jest program, w którym użytkownicy wpisują swoje zdarzenia. Każde nowe
zdarzenie musi generować sms-a na konkretny numer telefonu. Sms ów nie
jest informacją krytyczną, a jedynie treścią tzw. "do wiadomości". Nie
jest wymagane jej dostarczenie natychmiast, ale tak, jak jest to w
rzeczywistości - wysyłam i... czekam, aż dojdzie. Przy czym sądzę, że
kilka godzin oczekiwania zupełnie jest do przyjęcia, ale już kilkanaście
powoduje to, że treść tego sms-a staje się bezwartościowa, bo dana osoba
mogła już w programie dawno odczytać wiadomość.

A zatem musiałby istnieć jakiś mechanizm dzięki któremu będzie można
anulować dostarczenie sms-a. O ile takowy istnieje.

> 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.

To trochę ryzykowne, bo wpakowuję się w przepychanki prawne w razie
draki. W zasadzie nie chciałbym być "pomiędzy" i wolałbym, aby klient
miał z brokerem bezpośredni kontakt. Ja wolałbym tylko stworzyć
odpowiednie narzędzie do kontaktu pomiędzy klientem a brokerem.

> (...)
>
>> 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.

A zatem mogę ustawić ważność czasu wiadomości, ale anulować jej wysłania
nie mogę. Tak?

>> 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ść.

Ok, mechanizm jest zrozumiały.

> 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.

To ważne, aby mieć stały kontakt z brokerem.

> 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. :)
>
> (...)

Wygląda na to, że jest trochę z tymi sms-ami problemów, ale da się je
rozwiązać. Zapewne zależy wiele od jakości brokera i operatora.

>>> 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).
>
> (...)

Dziękuję. Zwrócę uwagę na pakiety. W sumie rzeczywiście może się okazać,
że jeśli średnia ilość na miesiąc wychodzi n, to może warto będzie
negocjować pakiety.

>>> 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. :)
>
> (...)

No cóż. Pierwszy raz badam ten temat, a zatem mogę błądzić ;-)

>>> 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.
>
> (...)

To takie działanie prewencyjne, ale potrzebne.

>>> 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ę).

Być może będzie możliwość "doszlifowania" API.

>> 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.

A to trochę nie do końca sprawiedliwe, bo w końcu anulowałem usługę i
nie powinna być ona wykonana. Myślę, że to mogą precyzować warunki
umowy, z którym trzeba się dokładnie zapoznać.

--
Peter