eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.wwwBramka sms, najlepiej płatnaRe: Bramka sms, najlepiej płatna
  • 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

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: