Facebook Graph API

Я довольно давно не затрагивал тему adaptive case management. Не затрагивал, не потому что она мне стала не интересной. Просто последние несколько месяцев у меня очень много работы, связанной с практической реализацией ИТ поддержки такого рода процессов. В первую очередь, речь идет о процессах решения телеком инцидентов. Это тысячи тикетов ежедневно, необходимость оперативного доступа к данным о клиентах, договорах, адресах подключений, данным по сетевому оборудованию и предоставляемым сервисам. Все это по-разному работает для разных типов услуг, линий бизнеса, в разных информационных системах. Этот практический опыт подтверждает мои предыдущие наблюдения. Если бы мне сейчас пришлось писать Adaptive Case Management Manifesto я бы начал с того, что гибкость бизнес-процессов достигается разделением приложений для совместной работы и приложений управления данными.

Если у вас есть хорошо структурированные данные, открытые для всех корпоративных приложений через эффективные программные интерфейсы, то вопрос обеспечения гибкости систем управления бизнес-процессами теряет свою актуальность. Вы можете реализовывать такие приложения на Java, BPEL, в движках поддерживающих BPMN и т.д. Завтра придут новые средства реализации бизнес-процессов, такие как subject oriented BPM (S-BPM) или что-то другое. Все эти приложения могут мирно уживаться друг с другом, если под ними будет находиться единый слой данных. Вы можете менять такие приложения и технологии по мере необходимости.

Чтоб в очередной раз не быть голословным в призывах использовать RESTful API и пр., несколько слов о том, как такого рода хранилище реализовано у Facebook. Я выбрал его потому, что «пощупать» Graph API фейсбука можно прямо из браузера без написания кода.

Как всем хорошо известно, фейсбук – это социальная сеть, состоящая из узлов и именованных связей между ними. Люди, группы, события, сообщения – это все узлы, имеющий свой уникальный идентификатор и доступные либо в виде веб страниц по ссылкам типа:

https://www.facebook.com/115085015172389 — в HTML формате для людей, или по ссылкам типа:
https://graph.facebook.com/115085015172389 — в формате JSON для машин(программ)

Впрочем, для работы с API удобнее использовать страничку Facebook-а Graph API Explorer краткое описание которого доступно здесь Introducing the Graph API Explorer.Эксплорер позволяет легко сгенерить аутентификационный токен и в дальнейшем работать с данными фейсбука ни в чем себе не отказывая (в рамках прав доступа).

Для просмотра узлов, связанны с данным узлом какими-либо отношениями  используются ссылки вида:

https://graph.facebook.com/115085015172389/friends — показывает друзей
https://graph.facebook.com/115085015172389/likes — показывает предпочтения и т.д.

Короткое и доступное описание Graph API: https://developers.facebook.com/docs/reference/api/
Более продвинутый раздел – подписки: https://developers.facebook.com/docs/reference/api/realtime/

Это все что надо, для того чтоб начать погружением в тему. Ну а то, как из разрозненных слабо документированных корпоративных хранилищ данных построить нечто подобное – это отдельный вопрос.

Я думаю, начать тренироваться можно с построения CMDB 3.0 о которой я совсем недавно писал в заметке Service Knowledge Management System и процессов управления ИТ отделом организации

Реклама

13 responses to “Facebook Graph API

  • Слава

    В этом контексте довольно интересной может быть тема построения некоторого социального dashboard для саппортов и поддержки решения тикетов:
    * (самое главное) доступного поиска по базе знаний и другим тикетам (используется API поиска Confluence и Jira) — с обязательным механизмом suggest (как в гугле), категоризации и рейтинга поиска, по которому в том числе саппорты довольно хорошо обучаются (по истории решения других подобных решаемым тикетов).
    * (нечто внутренней соц-сети) база пользователей (саппортов и внешних клиентов) на базе сервера OpenSocial (на базе Apache Shindig), где кроме относительно стандартных персональных данных, сохраняется глобальная история заказов клиента (ссылки на информацию в биллинге и др.), все факты взаимоотношений с клиентами (данные, ссылки, рейтинги), связи персоналий с внешними соц-сетями и др. И саппорты, и клиенты в одной БД, где между ними организуется граф с целью оптимизации их отношений (очевидно, клиенты не любят, когда их начинают бросать по телефонам). При продвижении продуктов через соц-маркетинг роль этой БД очевидна должна быть.
    * gadget-портал для возможности построения персонализированных GUI и упрощения разработки/интеграции компонентов (мы ориентируемся на использование Apache Shindig с авторизацией по OAuth и поддержкой Google Gadget). В том числе, никто не запрещает загружать сторонние gadgets (хотя проводится аудит того, что используют и поддерживается чёрный список, по которому часть gadgets нельзя загрузить в портале). Для каждой роли пользователя задаётся список и формат отображения обязательных gadgets (нельзя их сдвинуть или поменять положение на странице dashboard), которые обычно связаны с решаемыми ролью задачи (синдикации activity stream подчинённых, ведомых обращений, обновления документации, чаты и др.).
    * «пиналки» — отслеживающие жизненный цикл/статус тикетов, реализуется на базе Activiti, их задача очевидна (дедлайны, эскалации, журналирование и др.).

    Практически везде ссылки и REstfull API (atom/json). Подобная инфраструктура развивается в некоторой небезысвестной компании-провайдере ИТ:)

  • ailev

    Вообще-то говоря, есть современные архитектуры интеграции данных разнородных приложений. Например, архитектура «ISO 15926 outside» (http://fiatech.org/images/stories/techprojects/project_deliverables/iso-intro-ver1.pdf).

    Всё корпоративное — это мелочи по сравнению с тем, что происходит на отраслевом уровне. Ибо внутри предприятия можно выпустить какой-то архитектурный приказ, а вот между предприятиями этого сделать обычно нельзя…

    И еще одна засада: есть интеграция данных, и есть интеграция воркфлоу. В какой-то момент можно сообразить, что данные о воркфлоу и о собственно данные — это одно и то же, просто интегрируемые данные и интегрируемые вычисления….

  • maxxannik

    Ммм… да.
    Я правильно понимаю что у WordPress похожая архитектура?
    т.е. там есть Записи (как Узлы в Фейсбуке), которые можно настраивать и бить на виды. После чего можно до посинения выстраивать отношения между ними под любым углом, который зависит лишь от фантазии )
    Кстати я долго искал решение для связки постов в WP и нашел вот это http://wordpress.org/extend/plugins/advanced-custom-fields/
    Попробуйте. Уверен что вам понравится 🙂
    Плагин позволяет добавлять доп.поля к записям типа: ссылки на другие записи.
    Причем можно указывать кучу настроек.
    Например:
    1. у записей типа Задача, сделать доп.поле Ответственный и оно будет ссылаться на какую либо запись типа Сотрудники.
    2. И более того, можно прикреплять эти отношения не только к типу записи, но и к типу записи определенной категории. Например одно дело это Задача категории Инцидент ИТ, другое дело что может быть Задача типа «Увольнение сотрудника» — там кроме Инициатора, Ответственного — было бы здорово иметь ссылку на того сотрудника, которого нужно уволить. И система позволяет добавить эту ссылку и это поле только к Задачам категории: Увольнение сотрудников

    P.S. Слово Задача в этом тексте можно заменить на Кейс, Операцию или Тикет 🙂

    • Максим Смирнов

      Логически, архитектура, конечно, очень похожая. Но у фейсбука под этой моделью лежит логика распределения по узлам с mysql-ными базами, а у WP одна база из десятка таблиц. Вероятно, сейчас хранилища надо делать на чем-то более продвинутом, чем просто реляционная БД

      • Слава

        оффтопик: facebook съезжает с mysql шардингового кластера на инфраструктуру hbase в котором они пытаются заменять и уровень кэширования (сейчас memcached) и хранения в том числе транзакций (hbase — реализуется CP-свойства CAP-теоремы) и аналитики в почти реальном времени. Я считаю это правильным направлением движения, в проектах своей компании (массовые транзакции, аналитика больших объёмов данных) — развиваем такой же подход… пока удачно, но не так всё красочно как кажется на первый взгляд (собственно faceboook основные комитеры hbase):)

  • Open Graph. Третье поколение глобальной сети « Архитектура информационных систем

    […] удачной следует признать протокол Open Graph(см. , например Facebook Graph API). Социальные сети потянули за собой информационные […]

  • Open Graph: Третье поколение глобальной сети « Архитектура информационных систем

    […] удачной следует признать протокол Open Graph(см. , например Facebook Graph API). Социальные сети потянули за собой информационные […]

  • Open Graph: Третье поколение глобальной сети « Архитектура информационных систем

    […] следует признать протокол Open Graph (см. , например Facebook Graph API). Социальные сети потянули за собой информационные […]

  • 2012 in review « Архитектура информационных систем

    […] API. Сразу за топ-5 следует еще одно сообщение из 2012 года Facebook Graph API Сообщение, вообще-то, не столько про фейсбук, сколько […]

  • strekland

    Reblogged this on «Memento mori» and commented:
    Маркер доступа ( на ФБ ) — «access token».

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s