по договор за безвъзмездна помощ BG16RFOP002-1.001-0275-C01 по процедура BG16RFOP002- 1.001„Подкрепа за внедряване на иновации в предприятията”, Оперативна програма „Иновации и конкурентоспособност“ 2014-2020 г.”
ТЕХНИЧЕСКА СПЕЦИФИКАЦИЯ
по процедура за избор на изпълнител „Избор с публична покана“ с предмет:
„Разработване, доставка и въвеждане в експлоатация на специализиран софтуер – Специализирана софтуерна платформа за медиен мониторинг – 1 брой“,
по договор за безвъзмездна помощ BG16RFOP002-1.001-0275-C01 по процедура BG16RFOP002- 1.001„Подкрепа за внедряване на иновации в предприятията”, Оперативна програма „Иновации и конкурентоспособност“ 2014-2020 г.”
Специализирана софтуерна платформа за медиен мониторинг – 1 брой, с еквикалентни или по- добри параметри от следните минимални технически и фунционални характеристики:
1. Обзор на системата и основно описание
Специализираната софтуерна платформа за медиен мониторинг трябва да представлява комплексна система състояща се от бекенд част, способна да обновява милиони източници на новини (емисии) в рамките на минути, да сверява старото с новото съдържание на емисиите и да записва само новото съдържание в база данни. Всяка записана статия трябва да минава през редица филтри и правила, които всеки от потребителите на системата може да заложи и на база на които трябва да се предприемат действия – известяване, категоризиране в отчети и други описани по-подробно по- надолу в документа. Архитектурата на системата и базата данни трябва да е съобразена с обема, който ще постъпва. Системата трябва да е калкулирана да обработва и съхранява до 20,000,000 (20 милиона) статии всеки ден, да може да изтегля достатъчно бързо и паралелно емисиите, така че да може да обработва до 1 милион източника на час. За целта възлите на системата трябва да са оптимално добре издържани архитектурно и кодът да е написан на възможно най-ниското ниво, което позволява програмният език.
Потребителите трябва да могат да достъпват системата чрез Web интерфейс и мобилни приложения зa Android, iOS и Windows Phone.
Напредналите потребители и разработчици трябва да могат да достъпват системата и чрез приложно програмен интерфейс (API).
Системата трябва да има добър презентационен сайт (landing page) където да е показано какво прави, какви нужди удовлетворява и какви проблеми решава.
Тъй като ще се таргетира международна аудитория, системата трябва да бъде с основен език Английски и с вградена възможност за преводи. Да бъде предоставена система за автоматично превеждане от потребителите, за да бъде постигнат ефекта на crowdsourcing.
Основни характеристики:
− Възможност за следене на източници чрез RSS протокол;
− Възможност за следене на източници чрез OAuth2 оторизация и REST интерфейси;
− Възможност за следене на източници чрез входящи email съобщения;
− Разработване на модел за база данни, способен да съхранява неограничено количество информация чрез прилагане на добри практики за скалируемост и big-data;
− Разработване на приложни интерфейси за надграждане на платформата;
− Разработване на механизъм за автентикация на потребители;
− Разработване на абстрактен аналичитен модул за анализ на съдържанието на новините и съвпадението му с едно или повече предварително въведени правила.
Нефункционални спецификации:
− Програмен език: PHP;
− Бази данни: MySQL;
− Системата да бъде оптимизирана за работа върху POSIX операционни системи (Linux/UNIX);
− За автентикация на потребителите дасе използват само съвременни методи за криптиране (mcrypt) на пароли.
2. Архитектура на Специализирана софтуерна платформа за медиен мониторинг Архитектурна стратегия
Системата трябва да следва LAMP принципите, поради следните причини:
• Прозрачност и отворена среда на компонентите
• Огромна база от потребители и разработчици
• Безплатни дистрибуции и компоненти
• Бърза разработка и поддръжка на програмните езици и компоненти
Системата от гледна точка на потребителите трябва да бъде облачна услуга. При използване на Web browser потребителите не трябва да инсталират нищо, а само да насочат браузъра си към уеб сайта на системата. При използване на мобилно устройство с Android, iOS или Windows Phone, потребителите инсталират приложение от съответният Аpp Store, което работи като тънък клиент – използва приложно-програмният интерфейс на системата за оторизация, извличане и промяна на данни.
Задължително е системата да се инсталира на хардуер на „Иннолоджика” ООД.
Сървърна операционна система – Linux. Задължително поддръжани версии – CentOS 6 и нагоре, RedHat 6 и нагоре.
Уеб сървъри – Apache/mod_php, Apache/php-fpm или NGINX/php-fpm. Трябва еднакво добре да се поддържат и двата уеб сървъра и варианти на PHP.
Програмен език сървърна част – PHP. Задължителна поддръжка на PHP 7 Програмен език клиентска част (Web) – JavaScript, CSS, HTML. Програмен език клиентска част (iOS) - Visual C
Програмен език клиентска част (Android) - Java
Програмен език клиентска част (Windows Phone) - C#
Бази данни – MySQL, Elasticsearch. Задължително е използването само на МySQL 5.5 и нагоре, както и Percona Server. Elasticsearch не трябва да използва като основна, а само помощна база за търсене.
Позволени библиотеки - Yii2, jQuery, Vuejs, Bootstrap
Крайната система трябва да се придържа максимално към желана архитектура изобразена по-горе. Задължителен елемент е шината за обмен на данни (4). Тя е абстрактен слой чрез който различните модули обменят информация помежду си. Комуникация между модулите по други канали не бива да се осъществява. В шината трябва да може да се залагат различни прихващания (hooks) чрез които системата да може да се надгражда допълнително чрез плъгини.
Системата за автоматично уведомяване (9) трябва да поддържа уведомяване чрез следните методи:
• SMS
• Push notifications (Android и iOS)
Ядрото (5) трябва да съдържа в себе си модул за управление на процеси (6) и цялата бизнес логика в отделна абстракция, която да може да се разширява при нужда. Модулът за управление на процеси определя начинът на стартиране на backend процесите. Трябва да може да се стартират процеси по три начина:
• През интервал – процесът се стартира, извършва дейността си и излиза. Модулът следи за изтичане на зададеният интервал и го стартира отново. Така цикълът се затваря
• Периодично – задават се точни периоди на които процесът се стартира – примерно на всеки 5 минути, всеки час. Всеки понеделник в 10:00 и т.н. Преди стартиране на процеса
се прави проверка дали той вече не работи. Ако работи не се стартира повторно за да се предоврати проблем с данните
• Персистентен процес (xxxxxxxx) – в този режим се пускат процеси, които никога не трябва да спират. Ако случайно някой процес спре (поради фатална грешка например или друга непредвидена причина) той моментално трябва да се стартира отново.
В бизнес логиката (7) трябва да е заложена цялата логика по обработка на получените статии от източниците. Тя трябва да е добре структурирана, така че да може да се доразвива.
Специализираната софтуерна платформа за медиен мониторинг трябва да може да работи при следните параметри:
• До 10,000 едновременно логнати потребители на уеб интерфейса
• До 5,000 едновременно логнати потребители през мобилни приложения
• Да може да издържа до 20,000,000 нови статии на ден.
• Да може да складира статиите до безкрай само чрез добавяне на нови сървъри.
• Да може да обновява до 2 милиона източника на емисии в рамките на един час.
Специализираната софтуерна платформа за медиен мониторинг трябва да има предвидени вградени механизми за надежност и непрекъсваемост на услугата. Задължително е уеб сървърите да могат да се скалират хоризонтално при нужда. За целта трябва да се използва комбинация от NGINX и Apache сървъри както е на показаната архитектура:
Диаграма на уеб архитектурата на уеб сървърите
За надежност на базите данни трябва да се използва асинхронната репликация на MySQL, като превключването към Slave база не трябва да бъде автоматизирано.
Специализираната софтуерна платформа за медиен мониторинг трябва да бъде разработена при спазване на най-добрите практики в програмирането. Сървърната част трябва да бъде изцяло обектно ориентирана, като всички обекти, методи и свойства трябва да бъдат добре структурирани, така че да позволяват лесно преизползване в случай на нужда на разширяване на системата.
Специализираната софтуерна платформа за медиен мониторинг трябва да бъде бъде достатъчно оптимизирана, за да може да работи при параметрите описани в т. Скалируемост, без забележимо забавяне към потребителят. Средното време за отговор на приложно- програмният интерфейс не трябва да бъде по-високо от 20ms. Средното време за извеждане на страница в Web интерфейса не трябва да бъде повече от 200ms.
Специализираната софтуерна платформа за медиен мониторинг трябва да може да работи както автономно, така и да получава данни от външен източник на информация чрез консумиране на приложно-програмен интерфейс.
Портативност
Специализираната софтуерна платформа за медиен мониторингне трябва да бъде обвързана със специфичен хардуер и операционна система. Кода на системата трябва да се съхранява в git хранилище и при нужда да може да бъде изтеглен на нов сървър.
Специализираната софтуерна платформа за медиен мониторинг НЕ трябва да съдържа нито една от долупосочените уязвимости:
• Code injection: хакерите да намерят начини да вмъкват зловреден изпълним код чрез легитимен трафик.
• Слаба автентификация и управление на сесиите: компрометира самоличността на потребителите в най-различни начини
• Cross-сайт скриптове: подобно на инжектирането на код, но със скриптове изтеглени от несигурни източници
• Несигурните препратки към файлове: получаване на достъп до файлове, до които уеб сървърът не трябва да има достъп
• Излагане на чувствителни данни: Недобра защита на личните данни на потребителите (Имена, email адреси, телефонни номера), което в последствие да бъде използвано от недоброжелателни лица.
• Слаб контрол на нивата на достъп: Слаба проверка на текущото ниво на достъп на потребителят, даваща възможност на недоброжелател да повдигне нивото си на достъп по изкуствен път.
• Cross-site request forgery: Компрометиране на приложението, чрез предоставяне на валидирана, но подправена информация от трета страна.
• Компоненти с известни уязвимости: Използване на компоненти, които имат публичен достъп и имат известни уязвимости. Минимизирането на външни компоненти намалява този риск.
Всяка комуникация през потребителските и приложно-програмните интерфейси трябва да се осъществява посредством Secure Sockets Layer (SSL) без изключение.
Специализираната софтуерна платформа за медиен мониторинг трябва да поддържа различни нива на записване на грешки, които да могат да бъдат преглеждани по всяко едно време:
• Всеки unhandled expectionв PHP трябва да се записва.
• Всяка MySQL грешка трябва да се записва заедно с дата и време, IP адрес на сървъра от който е дошла, както и потребител в интерфейса.
• В процеса на събиране на данни от източниците трябва да се записва всяка грешка при изтегляне или анализиране на XML файловете.
• Логовететрябвапериодичнодасередуват и архивират.
Mониторинг и защита на процесите
Всички backend процеси трябва да се мониторират:
• Един и същи процес да не се стартира два или повече пъти в паралел.
• Дали един процес не работи подозрително дълго време (времето трябва да се конфигурира поотделно за всеки от процесите). Ако има такива системата трябва да алармира администраторите по email.
• Процесите трябва да изпращат т.нар. heartbeatsкъм централизирано място където да се проверява периодично, че всеки процес изпраща регулярно такива. Ако някой процес не изпраща системата трябва да алармира администраторите по еmail.
Модул “Ядро”
− Съдържа основната бизнес логика на приложението;
− Съдържа подсистема за управление на процеси и задачи. Дава възможност да се определят интервалите на които да се стартират определените задачи, какво да бъде максималното им работно време и запазва изхода от тяхната работа;
− Достъпа и ограничението на потребителите се осъществява в този модул;
− Паролите на потребителите са криптирани с mcrypt модул;
− Поддържат се следните външни доставчици на оторизация: Google, Facebook, Twitter, LinkedIn;
Модул “Потребителски”
− Представлява целият потребителски интерфейс на приложението;
− Да бъде написан използвайки модерни технологи и похвати – HTML5, jQuery, Bootstrap;
− Включва страница за презентация на системата (landing page);
− Поддържа нива на достъп, като има отделни потребителски и административни интерфейси;
Mодулът трябва да е т.нар. уеб фронтенд на приложението. Модулът трябва да е разделен на три основни части (портали) – презентационен портал, административен портал и потребителски (клиентски) портал. Те са разделени функционално, спрямо различните цели и нужди на потребителите и на„Иннолоджика“ ООД.
Целта на презентационният портал е да е презентира функционалността на системата (Специализираната софтуерна платформа за медиен мониторинг) пред нови и потенциални потребители. Представлява съвкупност от лендинг страници, на които попадат потребителите, които не са регистрирани и вписани в системата.
Основният език на презентационният портал трябва да бъде Английски, като трябва да има опция за смяна на езика. Трябва да се поддръжа и Български, както и да бъде предложена схема за превеждане от потребители.
Презентационният портал трябва ясно и точно да изтъква предимствата на системата, да показва как работи тя и да дава бърза възможност за регистрация с ясно изразени call-to-action бутони. Трябва също така да дава информация за цените и плановете на приложението. Задължително е да присъстват политика на конфиденциалност и условия за ползване.
На презентационният портал трябва да бъдат поставени на видно място логата на ЕС и Оперативна програма Иновации и конкурентоспособност 2014-2020. Файловете могат да бъдат намерени в оригинал на адрес xxxx://xxxx.xx/xxxxxxxxxxxx-x-xxxxxxxxxxx/xxxxxxxxx-xxxxxxxxxxx
Примери за добре разработени презентационни портали са:
Mention (xxxxx://xxxxxxx.xxx):
Brand24 (xxxxx://xxxxx00.xxx/):
Трябва да се поддържат основните методи за регистрация и вписване, които са Email/парола или социални мрежи (Facebook, Google, LinkedIn). Тези методи трябва да бъдат разработени в приложението и бекенда.
• Facebook login - xxxxx://xxxxxxxxxx.xxxxxxxx.xxx/xxxx/xxxxxxxx-xxxxx/xxx
• Google login - xxxxx://xxxxxxxxxx.xxxxxx.xxx/xxxxxxxx/xxxx-xx/xxx/
• LinkedIn login - xxxxx://xxxxxxxxx.xxxxxxxx.xxx/xxxx/xxxxx0
Потребителският портал е основната част, с която се борави в системата.
Основният език трябва да бъде Английски, като трябва да има опция за смяна на езика. Трябва да се поддръжа и Български език, както и да бъде предложена схема за превеждане от потребители.
Потребителския тпортал трябва да съдържа следните секции:
• Настройки
• Репорти
• Ключовидуми
• Статии
• Табло (Dashboard)
Потребителят трябва да има право да променя следните настройки:
• Име
• Потребителско име
• Парола
• Език
• Честота на операсняване на новините
• Включване/изключване на известия за новини (чрез Web Notifications)
Потребителите трябва да могат да генерират неограничено количество репорти.
Репортите са основно списъци от статии, които са съвпаднали с дадени ключови думи. В един репорт може да участват една или повече ключови думи. Репортите трябва да могат да се разглеждат по дни, седмици и месеци. Освен списъкци от статии и съвпадения в репортите трябва да има още:
• Графика на съвпаденията по дни
• Гъстота на ключовите думи (коя дума се среща най-често в репорта)
• Езици на статиите
Ключовите думи реално са правила, които потребителите дефинират и на база на които правила определени статии съвпадащи с тях трябва да се добавят към репорти или да се изпращат към модуала за автоматично известяване. Следните правила трябва да може да се дефинират от потребителите:
• Ключова дума присъства в заглавие/съдържание/автор
• Xxxxxxx дума не присъства в заглавие/съдържание/автор
• Ключова дума е в началото на заглавие/съдържание/автор
• Ключова дума е в краят на заглавие/съдържание/автор
Освен по ключови думи, потребителите трябва да могат да дефинират и регулярни изрази в търсенето си. Например /бойко(\s+)xxxxxxx/i за търсене на “Xxxxx Xxxxxxx” без значение от броят интервали, нови редове и табулации между двете думи.
Едно правило в потребителският интерфейс трябва да може да съдържа комбинация от различни ключови думи и типове на съвпадения.
Едно правило трябва да има избор дали да смята съвпадение при която и да е ключова дума или при съвпадение на всички.
Основна функционалност на системата е извличането на статии от медийни източници. Тези статии трябва да се визуализират подобаващо в потребителският интерфейс, като трябва да има различни режими на визуализация – списък, списание, картички. В режим списък, статиите трябва да се визуализират само по заглавия, като при избиране на статия тя се отваря в пълният й вид. В режим списание, освен заглавието в списъка трябва да се появява и снимка от статията, както и първите няколко реда от съдържанието. В режим картички трябва да се виждат големи снимки от статиите, както и заглавието на статията. В първите два режима статиите трябва да са по една на ред, а в режим картички да се виждат повече статии в зависимост от големината на екрана.
В таблото потребителите трябва да виждат основната информация, която може да ги интересува след влизане в системата. Това трябва и да бъде първият екран, който се визуализира след вход. Там трябва да се виждат следните неща:
• Новини от системата (обновления)
• Линкове към мобилните устройства
• Брой нови статии от последното влизане
• Генерирани нови репорти
• Списък с ключовите думи и брояч след всяка дума показващ броя съвпадения за дена
• Непрочетени нотификации
• Графика на статиите в репорти по дни
• Графика на гъстотата на ключовите думи
Трябва да може да се използва от служители на „Иннолоджика“ ООД, които да подреждат новинарскит еемисии, да преглеждат потребителите и техните плащания, да могат да ги обслужват пълноценно; да виждат различни статуси от модули на системата, например опашки от емисии за изтегляне, брой логнати потребители, брой регистрирани потребители за последният час/ден/седмица/месец.
Шина за обмен на данни (ESB):
− С цел по-добра модулност на системата, да се използва обща шина за обмен на данни между модулите;
− Комуникация между модулите чрез JSON;
− Възможност за логика в самата шина при постъпване на определени събития;
Модул “Агрегатор на данни”
− Сървърно независим - При нужда да може да се добавят допълнителни сървъри за хоризонтално скалиране;
− Работа с много паралелни процеси за постигане на оптимална работа при изтегляне на огромен брой източници едновременно;
− Може да чете източници по RSS, JSON, XML;
− Поддържа Basic HTTP Authentication;
− Поддържа OAuth2;
− Използва XML Xxxx за поправяне на проблемни RSS източници, така че да може да се прочитат коректно максимален брой;
− Разполага с конфигурация за броя процеси, които да се използват при изтегляне;
Модул “Агрегатор на данни” трябва да представлява система с висока производителност, способна да събира своевременно данни от различни източници, да ги уеднаквява до обекти от тип статия и да ги съхранява в базата данни за по-нататъшна обработка и презентация. Модул “Агрегатор на данни” трябва да може да скалира хоризонтално при нужда чрез добавяне на нови сървъри, които да обработват опашките от емисии.
Модул “Агрегатор на данни” трябва да се състои от няколко части:
Транспортна част – отговаря за изтеглянето на емисиите. Трябва да има сълно паралелизирана функционалност, устойчивост на мрежови грешки и опашка с повторни опити (exponential backoff). Тази част не трябва да съдържа бизнес логика и анализ на получените данни. Задължителна е поддръжката на HTTP Conditional GET за оптимизиране на мрежовият трафик и освобождаване на анализиращата част от излишна дейност. Примерен HTTP Conditional GET поток:
curl "xxxx://xxxx.xxxxxxxx.xxx/xxxx/" --header 'If-Modified-Since: Wed, 01 Mar 2017 20:24:24 GMT' --header 'If- None-Match: "cfed101f517d6b038f6f7129acecb647"' --silent –head
HTTP/1.1 304 Not Modified
Date: Wed, 01 Mar 2017 07:32:28 GMT
Connection: keep-alive
Set-Cookie: cfduid=d234947179b9fd99e6535cc442fb617f81488353547; expires=Thu, 01-Mar-18 07:32:27 GMT; path=/; domain=.xxxxxxxx.xxx; HttpOnly
Last-Modified: Thu, 15 Sep 2016 16:51:39 GMT ETag: "cfed101f517d6b038f6f7129acecb647"
Link: <xxxx://xxxx.xxxxxxxx.xxx/xx-xxxx/>; rel="xxxxx://xxx.x.xxx/" Server: cloudflare-nginx
CF-RAY: 338a6c29334264d5-FRA
Отсрещният сървър връща код 304 без съдържание в body-то, което означава, че документът не
се е променял от предишното изтегляне.
Транспортната част също така трябва да може да борави със всички OAuth токени на потребителите при изтегляне на емисии от REST интерфейси изискващи оторизация. Това са:
• Twitter REST API - xxxxx://xxx.xxxxxxx.xxx/xxxx/xxxxxx
• Facebook Graph API - xxxxx://xxxxxxxxxx.xxxxxxxx.xxx/xxxx/xxxxx-xxx
• Google+ API - xxxxx://xxxxxxxxxx.xxxxxx.xxx/x/xxx/xxx/xxxx/
• VK API - xxxxx://xx.xxx/xxx/xxxxxxx
В случай на грешка при изтегляне, това трябва да се отбелязва в лог файл на сървъра както и към самата емисия в базата данни. Последното е важно за да може потребителите да разбират кога дадена емисия изпитва затруднения и не се получават новини от нея.
Анализираща част (Parser) – отговаря за обработка на получените данни от транспортната част. Изходът от анализиращата част трябва да бъде унифициран обект, тип статия със следните свойства:
• Уникален идентификатор
• Заглавие
• Автор
• Съдържание (summary)
• Линк
• Дата на получаване (с точност до микросекунда)
• Дата на публикуване (с точност до секунда)
• Дата на последно обновяване (с точност до секунда)
• Списък с категории (link)
• Език (от детекторът на езици)
Форматите, които трябва да се поддържат от анализиращата част без допълнителна разработка са:
• RSS 0.90
• RSS 0.91 (Netscape)
• RSS 0.91 (Userland)
• RSS 0.92
• RSS 1.0
• RSS 2.0
• Atom 0.3
• Atom 1.0
• JSON
• Pure XML
Допълнителните именни пространства (link), които трябва да се поддържат са:
• Dublin Core 1.0
• Dublin Core 1.1
• GeoRSS
• iTunes RSS 1.0 (mostly complete)
• Media RSS 1.1.1
• RSS 1.0 Content Module
• W3C WGS84 Basic Geo
• XML 1.0
• XHTML 1.0
В допълнение за всеки от поддържаните JSON интерфейси трябва да има разширяема логика, чрез която избрани полета да се свеждат до свойства на статията.
Уникалният идентификатор на статията трябва да се определя в зависимост от вида на емисията и наличността на полетата. Той трябва еднозначно да идентифицира дадената статия за да се предотврати повторното и постъпване в базата данни при последващо изтегляне на същата емисия.
Датата на получаване трябва да бъде в микросекунди, тъй като се очаква в рамките на една секунда да се получават множество статии.
Свойствата Автор и Заглавие трябва да бъдат почистени от HTML и друг код.
Свойството съдържание може да съдържа HTML, но трябва да бъде почистено, така че да не съдържа зловреден код и елементи, които биха компрометирали поведението на потребителският интерфейс в последствие. Единствено следните HTML елементи са допустими:
a, em, i, p, br, b, strong, iframe, img, table, th, tr, td, div, span, pre, code, blockquote, h1, h2, h3, h4, h5, h6, small, ul, ol, li, tt, big, small, hr, address, cite, fdn, abbr, q, sub, sup, ins, del, caption, tfoot, thead, tbody, colgroup, col, object, embed, param, video, audio, source, strike
Единствено следните атрибути на HTML елементи са допустими:
src, style, href, title, alt, width, height, colspan, rowspan, dir, lang, frameborder, allowfullscreen, webkitallowfullscreen, mozallowfullscreen, name, value, type, preload, poster, loop, muted, autoplay , controls
Всички препратки с релативен адрес трябва да бъдат пренаписани към абсолютен използвайки
домейнът на емисията.
Детекторът на език е компонент, който трябва с голяма точност да определи език на който е написана статията. Езиците, които трябва да бъдат поддържани от детектора са следните:
• Afrikaans
• Arabic
• Bosnian
• Bulgarian
• Catalan
• Chinese Simplified
• Chinese Traditional
• Croatian
• Czech
• Danish
• Dutch
• English
• Estonian
• Finnish
• French
• German
• Greek
• Hebrew
• Hindi
• Hungarian
• Indonesian
• Italian
• Japanese
• Korean
• Latvian
• Lithuanian
• Malay
• Maltese
• Norwegian
• Persian
• Polish
• Portuguese
• Romanian
• Russian
• Serbian
• Slovak
• Slovenian
• Spanish
• Swedish
• Thai
• Turkish
• Ukrainian
• Urdu
• Vietnamese
• Welsh
В случай на грешка при анализиране, това трябва да се отбелязва в лог файл на сървъра както и към самата емисия в базата данни, за да може потребителите да разбират кога дадена емисия изпитва затруднения и не се получават новини от нея.
Дедупликираща част – при успешно анализиране, списъкът със статии трябва да се подаде към дедупликиращата част. Целият модул Агрегатор на данни трябва да работи на принципа “изтегляне на всичко, добавяне само на новото”. Статии, които вече присъстват в базата данни трябва да бъдат спрени от дедупликиращата част. Изхода от тази част трябва да бъде списък с нови статии. Изходът може да бъде и празен списък, което прекратява процеса по обновяване на текущата емисия, тъй като се смята че няма нови статии. Проверката за съществуване на стари статии трябва да става по оптимален начин, тъй като се очаква да се извършват хиляди подобни проверки в секунда. Нужен е кеширащ механизъм от ниско ниво в паметта, който да разтовари базата данни от постоянни проверки в таблици с милиарди записи.
Диаграма на работата на дедупликиращият модул
Проверка на ключови думи – в тази част всяка от статиите преминали през дедупликиращата част трябва да преминат проверка за съответствие по ключови думи, които потребителите на
системата трябва да могат да дефинират. Следните правила трябва да може да се дефинират от потребителите:
• Ключова дума присъства в заглавие/съдържание/автор
• Xxxxxxx дума не присъства в заглавие/съдържание/автор
• Ключова дума е в началото на заглавие/съдържание/автор
• Ключова дума е в краят на заглавие/съдържание/автор
Освен по ключови думи, потребителите трябва да могат да дефинират и регулярни изрази в търсенето си. Например /бойко(\s+)xxxxxxx/i за търсене на “Xxxxx Xxxxxxx” без значение от броят интервали, нови редове и табулации между двете думи.
Едно правило в потребителският интерфейс трябва да може да съдържа комбинация от различни ключови думи и типове на съвпадения.
Едно правило трябва да има избор дали да смята съвпадение при която и да е ключова дума или при съвпадение на всички.
При изпълнение на правило (има съвпадения) трябва да могат да се предприема комбинация от следните действия:
• Добавяне на статията към репорт
• Изпращане на статията по email
• Изпращане на SMS нотификация
• Изпращане на Push нотификация към мобилни устройства
Проверка на ключови думи и предприемане на действия
Модул “Приложно-програмни интерфейси”
− Превежда вътрешните интерфейси от ниско ниво в JSON интерфейси за използване на външни приложения;
− Поддържа OAuth2 и Username/Password authentication;
− Поддържа rate-limiting за намаляване на риска от претоварване на системата от външни системи;
Приложно-програмните интерфейси, трябва да използват REST (Representational state transfer) - разпределителна системна рамка, базирана на уеб протоколи и технологии. Архитектурният модел REST включва взаимодействията между сървър и клиент, осъществени по време на трансфера на данни.
Основният ендпойнт трябва да бъде достъпен на адрес xxxxx://xxxxxx/xxx/0/. Отговорите на методите трябва винаги да съдържат коректен HTTP response код.
Таблица с кодовете:
Код | Описание |
200 | Заявката и отговорът са коректни |
400 | Липсващ задължителен входящ параметър |
401 | Крайният потребител не е оторизиран |
404 | Методър не е имплементиран |
503 | Услугата не е налична – например проблем с база данни |
Примерна комуникация с грешка:
> POST /accounts/ClientLogin HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/0.00.0.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> Host: xxxxx-xxxxxxxxxx.xxx
> Accept: */*
> Content-Length: 27
> Content-Type: application/x-www-form-urlencoded
>
< HTTP/1.1 503 Service Temporarily Unavailable
< Date: Wed, 03 Feb2017 11:01:32 GMT
< Server: Apache
< X-Powered-By: PHP/7.1
< Vary: Accept-Encoding,User-Agent
< Content-Length: 0
< Connection: close
< Content-Type: text/html; charset=UTF-8
1. ClientLogin
За да може да се използват методите от приложно-програмният интерфейс е нужно потребителите да се оторизират. Това трябва да става по следният начин. Прави се HTTP POST заявка към xxxxx://xxxxxx/xxx/0/xxxxxxxx/XxxxxxXxxxx. Подават се следните два параметъра:
• Passwd
Като отговор трябва да се получи токен, който трябва да се съхранява в клиента и да се подава при всяка следваща заявка. Например:
> POST /accounts/ClientLogin HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/0.00.0.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> Accept: */*
> Content-Length: 27
> Content-Type: application/x-www-form-urlencoded
>
< HTTP/1.1 200 OK
< Date: Wed, 03 Feb2017 10:21:42 GMT
< Server: Apache
< X-Powered-By: PHP/7.1
< X-Mod-Pagespeed: 1.5.27.2-2912
< Vary: Accept-Encoding,User-Agent
< Cache-Control: max-age=0, no-cache
< Content-Length: 269
< Connection: close
< Content-Type: text/html; charset=UTF-8
<
Auth=xxxxxxxxxxx
Полученият параметър Auth се съхранява в клиента и се използва при всяка следваща заявка като хедър:
Authorization: Token auth=xxxxxxxxxxx
2. User information
Трябва да връща информация за текущо логнатият потребител. Прави се HTTP GET заявка към xxxxx://xxxxxx/xxx/0/xxxx-xxxx. Трябва да се получава JSON обект със следната структура:
{
userId: "1", userName: "customer",
userEmail: " xxxxxxxx@xxxxxxxxxx.xxx",
userPicture: "xxxx://xxxxxxxxxxxxxxxx.xxx/xxxxxxx.xxx", signupTime: 1163850013,
}
Целта е приложенията да показват информация за текущо логнатият потребител
3. Списък с ключови думи
{
keywords: [
{
id: "3614359203",
keyword: "Президент",
}
]
}
Xxxxxx да връща списък с дефинирани ключови думи. Прави се HTTP GET заявка към
xxxxx://xxxxxx/xxx/0/xxxxxxxx. Трябва да се получава JSON обект със следната структура:
Xxxxxx да бъде предоставен метод за странициране на резултатите, тъй като те може да са хиляди.
4. Списък със статии
Xxxxxx да връща списък със статии спрямо ключова дума. Прави се HTTP GET заявка към https://system/api/0/articles/{keyword} където {keyword} е url-encoded параметър – ключовата дума. Ако този параметър се проспусне трябва да се върнат всички статии. Трябва да се получава JSON обект със следната структура:
{
direction: "ltr", updated: 1424637593,
updatedUsec: "1424637593264558", items: [{
crawlTimeMsec: "1422046342882",
timestampUsec: "1422046342881684",
id: "123",
keywords: [
"Политика", "БСП"
],
title: "БСП и Подкрепа се харесаха, имали общи позиции",
published: 1422046320,
updated: 1422669611, canonical: [{
href: "xxxx://xxx.xxxx.xx/xxxxx/0000/00/00/xxx-x-xxxxxxxx-xx-xxxxxxxx-xxxxx-xxxxxx-xxxxxxx.000000"
}],
alternate: [{
href: "xxxx://xxx.xxxx.xx/xxxxx/0000/00/00/xxx-x-xxxxxxxx-xx-xxxxxxxx-xxxxx-xxxxxx-xxxxxxx.000000", type: "text/html"
}],
summary: {
direction: "ltr", content: "..."
},
author: "Dnes", comments: [], origin: {
streamId: "feed/xxxx://xxxx.xx", title: "Xxxx.xx",
htmlUrl: "xxxx://xxx.xxxx.xx/"
}
}]
}
Xxxxxx да бъде предоставен метод за странициране на резултатите, тъй като те може да са хиляди.
Модул “Автоматично уведомяване”
− Изпращане на уведомления по email;
− Изпращане на push notifications към iOS устройства чрез използване на APNS (Apple Push Notifications Service) протокол;
− Изпращане на push notifications към Android устройства чрез използване на GCM (Google Cloud Messaging) протокол;
− Изпращане на SMS чрез добавяне на съвместим SMS Gateway;
Модул “Автоматично уведомяване” трябва да реагира на заложени критерии при ключовите думи според които дадени съвпадение трябва да се изпращат към потребителите. Целта е дадени статии с особена важност да стигат до потребителите в реално време след постъвапе на статия в системата. Това трябва да става посредством опашка, която асинхронно да се разпределя към съответните канали:
• SMS
• Push notifications (Android и iOS)
Изпращането трябва да се осъществява непрекъснато като при грешка трябва да се правят последователни повторни опити с изчакване (т.нар. Exponential backoff).
Push нотификациите трябва да използват следните протоколи спрямо операционната система:
• Android – Firebase Cloud Messaging (FCM) - xxxxx://xxxxxxxx.xxxxxx.xxx/xxxx/xxxxx-xxxxxxxxx/
• iOS – Apple Push Notification Service (APNS) - xxxxx://xxxxxxxxx.xxxxx.xxx/xxxxxxxxxxxxx/
• Windows Phone – Windows Push Notification Service (WNS) - xxxxx://xxxx.xxxxxxxxx.xxx/xx- us/windows/uwp/controls-and-patterns/tiles-and-notifications-windows-push-notification-services-
База Данни:
− MySQL сървър версия 5.5;
− Използване на master – slave асинхронна репликация;
− Бекъпи на ключови таблици да се извършват на всеки час;
− Бекъпи на средни по важност таблици да се извършват един път дневно;
− Бекъпи на съдържание на статии да се извършва един път седмично. Повечето медийни източници поддържат отдалечено статии и могат да бъдат възстановени;
Поради очакваните огромни обеми от данни, базите трябва да оптимизирани и готови да поемат натоварването, като при нужда решението трябва да може да се скалира хоризонтално чрез добавяне на нови сървъри и без необходимост от преработки.
Релационни бази (RDBMS): Системата трябва да използва MySQL версия 5.5 или по-нова. Позволява се и използването на Percona Server. Задължително таблиците да бъдат с InnoDB/XtraDB engine.
Архитектурата на базата трябва да е така организирана, че да е възможно хоризонтално скалиране, тъй като се очаква в системата постепенно да се натрупат огромно количество данни, които не биха се побрали на един физически сървър.
Документални бази (NoSQL): За нуждите на търсене трябва да се използва Elasticsearch, като най- модерно решение. Задължително е индекса да бъде коректно настроен с поддръжка на най- популярните езици, включително CJK. Поддръжката не става автоматично, а трябва мапингите прецизно да се настроят за всеки език.
Xxxxxx сървър:
− Да поддържа статични HTML и PDF файлове с генерирани репорти с архивна цел;
− Файловете да са достъпни чрез HTTP интерфейс и токен оторизация;
Мобилни приложения:
− Разработване на мобилно приложение за Android, написано изцяло на Java с помощта на Android Studio;
− Разработване на мобилно приложение за iOS, написано на Objective C с помощта на Xcode;
− Разработване на мобилно приложение за Windows Phone, написано изцяло на C# с помощта на Visual Studio;
Мобилните приложения трябва да боравят с приложно-програмният интерфейс и да визуализират информация на потребителите, да дават възможност за дефиниране и промяна на ключови думи, правила и действия; да е възможо разглеждането на репорти, както и получаването на Push нотификации от модулът за автоматично уведомяване.
Основният език на приложенията трябва да бъде Английски, като трябва да има опция за смяна на езика. Трябва да се поддръжа и Български, както и да бъде предложена схема за превеждане от потребители.
Задължителни екрани в приложенията:
– Login и регистрационни екрани
Тези екрани трябва да се поддържат основните методи за регистрация и вписване, които са Email/парола или социални мрежи (Facebook, Google, LinkedIn). Тези методи трябва да бъдат разработени в приложението и бекенда.
• Facebook login
o iOS - xxxxx://xxxxxxxxxx.xxxxxxxx.xxx/xxxx/xxxxxxxx-xxxxx/xxx
o Android - xxxxx://xxxxxxxxxx.xxxxxxxx.xxx/xxxx/xxxxxxxx-xxxxx/xxxxxxx
• Google login
o iOS - xxxxx://xxxxxxxxxx.xxxxxx.xxx/xxxxxxxx/xxxx-xx/xxx/xxxxx-xxxxxxxxxxx
o Android - xxxxx://xxxxxxxxxx.xxxxxx.xxx/xxxxxxxx/xxxx-xx/xxxxxxx/xxxxx-xxxxxxxxxxx
• LinkedIn login
o iOS - xxxxx://xxxxxxxxx.xxxxxxxx.xxx/xxxx/xxx-xxx-xxxx
o Android - xxxxx://xxxxxxxxx.xxxxxxxx.xxx/xxxx/xxxxxxx-xxx-xxxx
– Екрани за манипулация на ключови думи
Тези екрани трябва да се извежда списък със всички дефинирани от потребителя ключови думи. При тапване върху ключова дума трябва да се влиза в резултатите за нея (статии). При задържане на пръста върху която и да е ключова дума трябва да се показва контекстно меню с 4 избора:
• Преглед на резултатите – отваря списък със статии
• Репорти – отваря всички репорти в които участва тази ключова дума
• Редактиране – дава възможност за промяна на ключовата дума
• Изтриване – изтрива ключовата дума. Трябва да се мине през потвърждение на потребителя
– Екран за настройки
– Екрани за статии
Списъците със статии трябва да съдържат заглавие на статията, дата, източник и кракто резюме на съдържанието. При тапване въху статия трябва да се влиза в цялостният й изглед както е бил в RSS summary полето или content от JSON интерфейс. При тапване на Share бутона горе в дясно трябва да се отваря стандартният sharing sheet на iOS или sharing intent на Android. При тапване върху заглавието на статията, тя следва да се отвори в браузър, като той се навигира към оригиналното URL на статията.
– Главно меню “хамбургер”
Главното меню трябва да служи за бърза навигация от която и да е точка на приложението. В него трябва да има следните елементи:
• Настройки
• Статии
• Източници
• Ключови думи
• Репорти
• Изход (отписване от акаунта, не реален изход)
Към техническите и функционални характеритики, които предлага Кандидатът, трябва да бъде представена демонстрационна визуализация – следните макети (визуализации) на екрани в статичен или динамичен вид (в pdf/jpeg/png/html или еквивалентен формат) за Специализирана софтуерна платформа за медиен мониторинг, с графично и текстово съдържание, съгласно посоченото:
Макети на екрани (web) за Модул “Потребителски” в статичен или динамичен вид (в pdf/jpeg/png/html или еквивалентен формат)
Макет на екран/и | Описание | |
1 | Презентационен портал | Макетът трябва да изобразява формата за логин чрез потребителско име и парола, линк за възстановяване на забравена парола, както и трите алтернативни метода за логин - Google, Facebook, LinkedIn. Също така трябва да е видима опцията за промяна на езика. |
2 | Настройки | Макетът трябва да показва панел с настройки. Следните настройки трябва да бъдат показани: • Име • Потребителско име • Парола • Език • Честота на опресняване на новините • Включване/изключване на известия за новини (чрез Web Notifications) |
3 | Репорти | Макетът трябва да показва отворен репорт. Репорта представлява списък със статии от съвпаденията по ключови думи, както и следната информация: • Графика на съвпаденията по дни • Гъстота на ключовите думи (коя дума се среща най- често в репорта) • Езици на статиите |
4 | Ключови думи и правила | Трябва да бъдат представени два екрана - един със списък от ключовите думи и втори - с конфигурация на определена дума. Първият екран трябва да показва списък с конфигурираните потребителят ключови думи. Трябва да има бутон за добавяне на нова ключова дума. В списъка трябва да се вижда думата, бърз бутон за активация/деактивация, бутон за изтриване както и брой попадения за днешният ден. Вторият екран е конфигурация на дадена ключова дума. Трябва да се отваря в дясната част на екрана като модален диалог. Трябва да може да се конфигурира името, както и списък с правила спрямо изискванията, посочени в секция "Ключови думи и правила" от Техническата спецификация към процедурата, както и да има бутони за запис (Save) и отказ (Cancel). |
5 | Статии | Трябва да бъдат представени четири екрана - за режим "Списък", режим "Списание", режим "Картички", както и екран с отворена статия. Над списъка със статии трябва да има ясен компонент (бутони) за промяна на изгледа. В режим "Списък" трябва всяка статия да заема един ред от екрана като е видим източникът на статията, нейното заглавие и датата ѝ. Източниците трябва да бъдат обозначени със икони както и име. В режим "Списание" статиите трябва да бъдат |
представени като контейнери с фиксирана широчина и височина. В лявата част на контейнера трябва има снимка от статията, а в дясната трябва да са видими заглавието, датата, и източникът. Височината на статиите трябва да бъде поне 80 пиксела, широчината поне 600 пиксела. В режим "Картички" статиите са представени като списък от контейнери с фокус върху изображението , което трябва да заема над 90% от размера на целият контейнер. Заглавието на статията и датата трябва да бъдат разположени върху самото изображение с подходяща маска или сянка на текста така че да бъде четим при всякакви условия. Източникът на статията може да бъде под изображението, но отново да бъде част от картичката. Препоръчителни размери: хоризонтално 300 пиксела, вертикално 240 пиксела. Екранът с отворена статия трябва да показва модален диалог отворен в дясната част на екрана. Най-отгоре трябва да бъде видим източника на статията, след това заглавието с подходящ голям шрифт. Под него датата и след това съдържанието на самата статия. | ||
6 | Табло | Макетът трябва да показва: • Новини от системата (обновления) • Линкове към мобилните устройства • Брой нови статии от последното влизане • Генерирани нови репорти • Списък с ключовите думи и брояч след всяка дума показващ броя съвпадения за дена • Непрочетени нотификации • Графика на статиите в репорти по дни • Графика на гъстотата на ключовите думи |
7 | Административен портал | Трябва да бъдат представени три екрана - Емисии, Потребители и Плащания. Екранът с емисии трябва да показва таблица с емисиите в системата. Трябва да са видими името, рейтинг на емисията, статии които се публикуват на ден, последно обновяване, статус от последното обновяване. Екранът с потребители трябва да показва таблица със следните полета: Име на потребителя, ел. поща, Държава, Дата на регистрация, Реферер (от къде е регистриран), бутон за изтриване. Също така трябва да има графика с броят потребители, които са онлайн в момента в системата, както и статистика за новите регистрации за последният час, ден, седмица и месец. Екранът с плащания трябва да показва таблица със следните полета: Потребител, Ел. поща, Дата, Сума, План, Статус. |
Макети на екрани за Mобилни приложения в статичен или динамичен вид (в pdf/jpeg/png/html или еквивалентен формат)
Макет на екран/и | Описание | |
1 | Логин екран | Макетът трябва да изобразява формата за логин чрез потребителско име и парола, както и трите алтернативни метода за логин - Google, Facebook, LinkedIn. Език – Български или Английски. |
2 | Регистрационен екран | Макетът трябва да изобразява формата за регистрация чрез потребителско име и парола, както и трите алтернативни метода за регистрация - Google, Facebook, LinkedIn. Език – Български или Английски. |
3 | Забравена парола | Макетът трябва да изобразява формата за изпращане на забравена парола по мейла. Език – Български или Английски. |
4 | Ключови думи | Макетът трябва да представлява Списък от свързани екрани, които трябва да изобразяват интеракции с ключови думи – Разглеждане на списъка с ключови думи, Изтриване, Редактиране, Разглеждане на репортите в които ключовата дума участва, Разглеждане на статиите записани към всяка ключова дума. Език – Български или Английски. |
5 | Настройки | Макетът трябва да изобразява екран със следните настройки: Име, Email, Парола, Език Език – Български или Английски. |
6 | Статии | Макетът трябва да представлява Списък от свързани екрани, които трябва да изобразяват интеракции със статии – Списък със статии -> Единична статия -> Шерване на статията към външни приложения, Преглед на статията в браузър. Език – Български или Английски. |
7 | Главно меню | Макетът трябва да изобразява Главно меню – тип "Хамбургер меню" с бутон горе в ляво, чрез който да се отваря и затваря. В менюто трябва да присъстват следните елементи - Настройки, Статии, Източници, Ключови думи, Репорти, Изход. Език – Български или Английски. |
Екраните за Android, iOS и Windows Phone трябва да бъдат еднакви. Допускат се Wireframe прототипи. | ||