Розбіжності

Тут показані розбіжності між вибраною ревізією та поточною версією сторінки.

--- opayzsmsnotify [2023/06/15 21:28]
bobr
+++ opayzsmsnotify [2024/10/24 13:16] (поточний)
bobr [Трохи механіки]
@@ Рядок 17: / Рядок 17: @@
   * Увімкнення, вже звично, здійснюється опцією **OP_SMS_NOTIFY_ENABLED**.
   * Текст нотифікашок задається опцією **OP_SMS_NOTIFY_TEXT**. Тут варто відзначити підтримувані на даний момент макроси:
-    * **{LOGIN}**** - логін абонента
+    * **{LOGIN}** - логін абонента
     * **{USERONLINELEFTDAY}** - кількість днів оплаченої послуги (0 у разі, якщо послугу відключено)
     * **{USERONLINETODATE}** - дата, до якої оплачено послугу (поточна дата в разі, якщо послугу відключено)
@@ Рядок 29: / Рядок 29: @@
 ==== Трохи механіки ====
 Робота цього функціоналу доволі нехитра: дивимося в таблицю платежів, забираємо з неї OpenPayz платежі за останні **OP_SMS_NOTIFY_PAYMENTS_PULL_INTERVAL** хвилин, складаємо їх в окрему службову табличку (перед тим перевіривши існування в ній уже "пронотифікованих" із щойно обраних та виключивши їх), відправляємо сповіщення, проставляємо статус "надіслано" в службовій табличці. \\
-Чому важливо, щоб **OP_SMS_NOTIFY_PAYMENTS_PULL_INTERVAL** був хоча б на **//одиницю//** більшим, ніж частота викликів **opayzsmsnotify** з [[remoteapi|RemoteAPI]]? - щоб уникнути "проігнорованих" платежів. Під час вибірки платежів для процесингу з таблиці платежів на **//поточну_дату_час//** сервіс спирається тільки на самому початку, у момент найпершого запуску, а весь інший час він бере **//дату_час// останнього обробленого(пронотифікованого) платежу**, і вже саме з цього таймстампа віднімає ті самі **OP_SMS_NOTIFY_PAYMENTS_PULL_INTERVAL** хвилини, отримуючи **//дату_час//**, починаючи з якої і забиратимуться платежі з таблиці платежів. Так, незважаючи на те, що "вжито всіх можливих заходів", існує ймовірність, що конкретно взятий OpenPayz платіж потрапить десь у "зазор" між запуском із крону та **OP_SMS_NOTIFY_PAYMENTS_PULL_INTERVAL** і буде просто проігнорований, тому що за своїм таймстампом не потрапить у вибірку. \\
+Чому **важливо**, щоб **OP_SMS_NOTIFY_PAYMENTS_PULL_INTERVAL** був хоча б на **//одиницю//** більшим, ніж частота викликів **opayzsmsnotify** з [[remoteapi|RemoteAPI]]? - щоб уникнути "проігнорованих" платежів. Під час вибірки платежів для процесингу з таблиці платежів на **//поточну_дату_час//** сервіс спирається тільки на самому початку, у момент найпершого запуску, а весь інший час він бере **//дату_час// останнього обробленого(пронотифікованого) платежу**, і вже саме з цього таймстампа віднімає ті самі **OP_SMS_NOTIFY_PAYMENTS_PULL_INTERVAL** хвилини, отримуючи **//дату_час//**, починаючи з якої і забиратимуться платежі з таблиці платежів. Так, незважаючи на те, що "вжито всіх можливих заходів", існує ймовірність, що конкретно взятий OpenPayz платіж потрапить десь у "зазор" між запуском з крону та **OP_SMS_NOTIFY_PAYMENTS_PULL_INTERVAL** і буде просто проігнорований, тому що за своїм таймстампом не потрапить у вибірку. \\
 Саме тому наполеглива рекомендація: якщо рядок у кронтабі у вас виглядає якось так:
 <code cli>

Ubilling Wiki

Користувальницькькі налаштування

Налаштування сайту

Розбіжності

Налаштування сторінки