-
Data: 2009-07-18 08:28:43
Temat: Re: Bramka sms, najlepiej płatna
Od: Peter <p...@p...fm> szukaj wiadomości tego autora
[ pokaż wszystkie nagłówki ]Konrad Kosmowski pisze:
> ** Peter <p...@p...fm> wrote:
>
>>> Ile tych SMSów chcesz wysyłać miesięcznie?
>
>> Tego tak na prawdę nie wiadomo. Wiem jedno: nie będzie setek tysięcy. Sądzę,
>> że to będzie ilość na poziomie kilkuset. Może kilka tysięcy, choć wątpię.
>
> Ale bierzesz pod uwagę ew. rozwój itd.?
Zależy, jak zdefiniujemy ten "rozwój". Raczej nie przewiduję, aby był
bardzo progresywny. Cała rzecz w tym, że usługa ta jest potrzebna do
powiadamiania o nowym zdarzeniu w określonym programie. Natomiast ilość
tych zdarzeń nie rośnie w tempie "kwadratowym".
> (...)
>
>>> Jakie masz wymagania dotyczące dostępności usługi (SLA)?
>
>> W ciągu 1-2h musi sms być wysłany.
>
> Takie SLA to będzie dodatkowe *kilka* tysięcy złotych miesięcznie - nie wiem
> czy przy tej skali (kilkaset SMS miesięcznie) w ogóle Ci się to będzie
> kalkulować bo wyjdzie jakieś 4 złote za SMS (tak z grubsza licząc 500 i 2000zł
> za SLA).
>
> Tzn. pytanie jest - co jeżeli SMS w ciągu 1-2h nie zostanie wysłany? Jedyna
> sensowna konstrukcja to jest kara pieniężna dla dostawcy np. za każdego nie
> wysłanego w terminie SMSa dostawca płaci 50zł.
>
> Szczerze mówiąc Twoje wymaganie w tym zakresie jest stosunkowo wysokie -
> porozmawiaj z beneficjentem/sponsorem tego systemu i wyjaśnij mu, że
> zapewnienie dostępności na tym poziomie po prostu kosztuje - przecież dostawca
> musi zapewnić sztab operatorów monitorujących 24/7/365, sztab administratorów,
> którzy są w stanie reagować 24/7/365 oraz utrzymać nadmiarowość infrastruktury
> (w zasadzie backupowe DC).
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:
* 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ść)
* beneficjent takiej usługi nie musi ponosić kosztów z tytułu utrzymania
wysokich warunków SLA
Wynika z tego, iż muszę ustalić, czy wiadomość wysłana sms-em jest
priorytetowa. W tym sensie, czy jej dostarczenie jest bezwzględnie
wymagane w ciągu określonego czasu, czy też nie jest. Jeśli założę (na
ten moment), że dostarczenie sms-a nie jest istotne w sensie 1-2h, no to
przynajmniej jedną sprawę będę miał jasną. 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.
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?
>>> Chcesz wysyłać po jednym SMSie czy bawić się w pakiety (coś w rodzaju sesja
>>> N*pytanie-odpowiedź)?
>
>> Po jednym w zasadzie.
>
> Czyli tylko wysyłać - bez interakcji i odbierania?
Tak, ponieważ ten sms zawierać ma informację "tylko do odczytu".
>>> SMS ma być wysyłany z numeru (nadawca np. 9123 - można
>>> oddzwonić/odpowiedzieć) czy tekstowego identyfikatora (nadawca np. PeterCorp
>>> - nie można oddzownić/odpowiedzieć)?
>
>> Tekstowego identyfikatora.
>
> 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.
>>> Odnośnie API to czy zadowala Cię jedynie coś w rodzaju fire-and-forget
>>> (wyślij i zapomnij) i potem miesięczne zestawienie czy chcesz też okresowo
>>> sprawdzać status wiadomości (doręczona, niedoręczona)?
>
>> Na razie "fire-and-forget".
>
> To jak chcesz weryfikować czy dostawca nie wystawia Ci złej faktury? Nie chodzi
> mi implikowanie złej woli w przypadku takich pierdalamentów w rodzaju różnicy
> kilku złotych tylko o to, że jak to się mówi kontrola najwyższą formą zaufania.
> :)
No ba! "Zaufanie to piękna rzecz, ale kontrola jeszcze lepsza" - to
prawda. Praktycznie powinno dać się zweryfikować to, bo przecież za
pomocą jakiegoś API wysyłam sms-a i mogę zliczać liczbę wysyłek. Pytanie
czy takie coś wystarczy? A co z tymi sms-ami, które anulowałem? (o ile
da się)
> 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.
>>> Odnośnie API to czy chcesz za pomocą niego jednocześnie kontrolować
>>> rozliczenie usługi (np. autoryzować płatność za każdego SMS na podstawie
>>> przekazanego do bramki tokenu, który pojawia się w zwrotnym zestawieniu)?
>
>> Nie. Przynajmniej w początkowej fazie działania usługi.
>
> Moim zdaniem jednak warto coś takiego mieć (chociażby dla kontroli działania) -
> jeżeli API to udostępnia i nie trzeba za to dopłacać to warto.
>
> Tzn. chodzi mi o coś takiego, że wywołując wysłanie SMS np. za pomocą
> pseudokodu:
>
> sendSMS(rcpt,body,id)
>
> W parametrze id przekazujesz jakiś identyfikator i potem w miesięcznym raporcie
> z rozliczeniem masz listę wszystkich SMS w formie tabeli:
>
> data,status,rcpt,body,id
>
> 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. 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ę.
--
Peter
Następne wpisy z tego wątku
- 18.07.09 08:30 Peter
- 20.07.09 23:04 Konrad Kosmowski
- 22.07.09 20:41 Peter
- 22.07.09 21:31 Konrad Kosmowski
- 23.07.09 18:11 Peter
Najnowsze wątki z tej grupy
- Jakie znacie działające serwery grup dyskusyjnych?
- is it live this group at news.icm.edu.pl
- php, linki z nazwami a $_GET, SEO
- www polityka pl captcha
- dyktatura brudnego palucha
- www.znanylekarz.pl
- Czy pytanie o sczytywanie stron programami/skryptami to tu?
- Grupy webdevowe
- Jak wydrukować stronę?
- IIS, kilka witryn
- linki <a href="/strona.php"> (ze slashami)
- co rozszerza stronę??
- responsywny akapit <p>
- Czy istnieje jakiś emulator przeglądarek pod Mac'a?
- taka sama konfiguracja dla localhost i produkcji
Najnowsze wątki
- 2024-11-14 Dobra zmiana
- 2024-11-14 Czy prezydent może ułaskawić od zadośćuczynienia? [A. Lepper odszkodowania]
- 2024-11-14 Gliwice => Network Systems Administrator (IT Expert) <=
- 2024-11-14 Gliwice => Administrator Systemów Sieciowych (Ekspert IT) <=
- 2024-11-13 Filtr do pompy ruskiej
- 2024-11-12 Gdzie kosz?
- 2024-11-13 elektrycznie
- 2024-11-12 Jebane kurwa, kurwy.
- 2024-11-13 karta parkingowa
- 2024-11-13 Wl/Wyl (On/Off) bialy/niebieski
- 2024-11-12 I3C
- 2024-11-13 Kraków => DevOps Engineer (Junior or Regular level) <=
- 2024-11-13 Łódź => Senior SAP HANA Developer <=
- 2024-11-13 Zabrze => Senior PHP Symfony Developer <=
- 2024-11-13 Karlino => Konsultant wewnętrzny SAP (FI/CO) <=