Всем привет!
кто то может сказать, если ли в стандартном функционале СФ возможность для мгновенных уведомлений?
т.е. юзер может находится на любой стандартной странице внутри СФ орга, и внутри браузерного окна всплывают (и исчезают) уведомления с какими то важными бизнес событиями?
так как например всплывают уведомления на макбуке... но вы поняли о чем я :)
Только если он в консоли. Я имею в виду Sales console, Service console. Хрень эта называется Omni Channel
Когда захожу первый раз в Lightning UI, то Chrome у меня спрашивает, можно ли уведомления показывать с этого сайта. Может в Lightning есть.
А Chatter для этого нельзя использовать?
Помню раньше на классике внизу постоянно маячила вкладочка Chatter.
Правда сам никогда ей не пользовался.
Кстати, это правильная мысль.
это был не Чатер, а Чат. Это не одно и то же.
а он обновляет в реалтайме? он есть на каждой странице?
спасибо, посмотрел
Значит я про чат писал. Его нельзя использовать для твоих целей? Он не каждой странице? и не обновляется в реалтайме?
Я просто ни чаттером ни чатом не пользовался. Даже серьезно только сегодня узнал что это разные штуки 
кто то может сказать, если ли в стандартном функционале СФ возможность для мгновенных уведомлений?
т.е. юзер может находится на любой стандартной странице внутри СФ орга, и внутри браузерного окна всплывают (и исчезают) уведомления с какими то важными бизнес событиями?
так как например всплывают уведомления на макбуке... но вы поняли о чем я :)
Стандартного такого функционала нет, насколько я знаю, но сразу пришло в голову что можно в home side-bar встроить компонент, в нем подписаться на события через Streaming API и показывать нужные пользователю нотификации.
С side-bar точно работать будет.
Ставил и настраивал пакет, который вешает в side-bar страничку. Как только кто-то закрывает Опп - там звонит звонок и показывает информацию об Опп.
Как реализовано - не знаю. Скорей всего, каждые пару секунд на страничке дергается метод, проверяющий закрытые Опп.
вот это первое, что приходит в голову
вот это второе, что приходит в голову... и так пару тысяч пользователей? :)
Та хоть миллион. Какая разница? Ты как пользователь дергаешь SOQL каждую секунду. Лимитов на SOQL в час нет. Дергай, сколько влезет. Ну, или я не понял вопроса. В моем случае - меньше 10 пользователей.
Если делать Visualforce страницей, то я б использовал
apex:actionPoller
Тут вся соль вопроса в наличии этой фичи на ВСЕХ страницах, а не только на кастомных. На кастомных это можно реализовать намного лучшим способом чем apex:actionPoller.
А на счет "дергай сколько влезет". Была такая же тема давным давно у одного клиента. Тоже делали через apex:actionPoller который дергали сотни пользователей. Звонили из самого SF и просили так не делать потому что создается избыточная нагрузка. Понятно что все в пределах лимитов, но им это не нравится и как вариант они тупо могут снизить приоритет обработки ваших запросов и только не только apex:actionPoller начнут тормозить, но и все остальное. Не знаю что там в деталях клиенту служба поддержки описала, но клиент попросил очень быстро избавиться от этой логики (заменили с реалтайм на простое получение сообщений при загрузке страницы - в принципе клиент не сильно потерял в итоге - ну не получали сообщение в реалтайм, а по очередной загрузке страницы, но оказывается реалтайм и не нужен был).
Есть же Platform Event забудьте про лонг пулинг.
Да, согласен, Platform Event тут должны работать.
Если ты в side-bar запихнул страницу, то неважно, отображается она или нет, она работает.
Печально это. Видимо, к пакетам другое отношение.
Недавно увидел в доках эту штуку, тоже считаю хорошим вариантом для интеграций, но пока не успел попробовать на практике.
вот смушает что внешние клиенты могут подписываться на события по протоколу CometD
https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_subscribe_cometd.htm
Умеет ли браузер? (пока не гуглил )
Через API умеют все ;-)
Апи тут не при чем.
Это протокол поверх http
Кстати я тут смотрю и оказывается Commet это протокол который построен на базе long polling
вот выдержка
Streaming API uses the Bayeux protocol and CometD for long polling.
Bayeux is a protocol for transporting asynchronous messages, primarily over HTTP.
CometD is a scalable HTTP-based event routing bus that uses an AJAX push technology pattern known as Comet. It implements the Bayeux protocol.
Long polling, also called Comet programming, allows emulation of an information push from a server to a client. Similar to a normal poll, the client connects and requests information from the server. However, instead of sending an empty response if information isn't available, the server holds the request and waits until information is available (an event occurs). The server then sends a complete response to the client. The client then immediately re-requests information. The client continually maintains a connection to the server, so it’s always waiting to receive a response. In the case of server timeouts, the client connects again and starts over.
Блин, а я чет думал что Salesforce все таки используют веб сокеты.
Вообще не круто!
Ну ладно! Им виднее.
А в общем для информации - все эти веб сокеты и обертки над long polling нужный чтобы не "бегать" на сервер за обновлениями, а сервер сам слал сообщения по событиям. Клиент только устанавливает соединение и сидит слушает.
А, ну в общем кому интересно продолжение темы.
Погуглил тут немного и по ходу браузер норм переваривает этот протокол. Вернее есть либа для Javascript
https://docs.cometd.org/current/reference/#_javascript
А еще есть примеры вот отсюда
https://developer.salesforce.com/docs/atlas.en-us.api_streaming.meta/api_streaming/code_sample_generic_vfp_deploy_project.htm
Ну и немного почитав оф доку по CometD понял что это не просто long polling а это комбайн который может и websocket если есть поддержка. Просто по ходу SF реализовал через long polling чтобы не заморачиваться и обеспечить максимальную поддержку.
Все правильно, там либо вэб сокеты, либо лонг пуллинг, чтобы поддерживать совместимость.
Использовали уже в реальном проекте?
пока только в прототипе
Была ситуация, когда поставили пакет на оргу, а в пакете side-bar страничка, которая при загрузке делает query 40k записей. Через час пришло письмо с SF что у них сработала защита и производительность нашего орга снижена.
Т.е. без разницы кто или что делает пробивает скрытые лимиты, письмо пишется владельцу орга.
Как интересно... Можно было бы и догадаться, но не верилось бы.
использовал Streaming API и соответственно CometD в реальном проекте
у нас была такая супер огроменная страница которая оверрайдила Opportunity, на ней была вся инфа сэйлзу как продавать и чего спрашивать у клиента пошагово (продавали солнечные панели). Со страницы можно было отправить запрос в инженеринг где эти солнечные панели с инвенторами собирали под заказчика индивидуально (потребление в месяц, направление крыши, угол наклона etc) и строили ему на крыше по картинке на гуглмапс. Строилось это за 5 минут пока сэйлз еще висит на телефоне, после чего приходило streaming API уведомление что панель готова (создавался Opportunity дочерний обьект со всеми данными включая картинку) и сэйлс в том же звонке показывал клиенту готовое решение и реальные цифры.
Бизнесу так хорошо зашло что я потом весь асинхрон сделал уведомлениями. Например клиент залогинился и подписал документы - бац сразу уведомление.
