Любите ли вы готовить так, как это люблю делать я? А готовить в программном коде? Не лукавьте, признайтесь, что самые «вкусные» рецепты переходят из поколений в поколения. Я уже однажды поделился «постным» рецептом как приготовить паттерны проектирования (иногда вздрагиваю и краснею, что слегка «пересолил» с той реализацией). Клянусь, но следующий рецепт мне приснился во сне, и я не преминул его утром же реализовать. Можно ли «приготовить» свой деббагер за 90 строк apex-кода? Нет ничего не возможного. Готовим.
Для приготовления дикого блюда нам понадобиться смешать следующие ингриденты:
Salesforce.com; 90 строчек apex кода; mailgun.com; Custom setting (по вкусу, не обязательно); голова на плечах (обязательный компонент).
Итак, немного лирики и пояснения, что я хочу сделать:
Что же столкнуло с места меня на столь дерзкий шаг, а именно тягаться с SF-овским деббагером? Признаюсь, новый проект, а точнее их россыпь. Мне дико не хватало времени все уследить и за все исправить. Плохой сон, переживания, и, наконец, прозрение одной ночью – я напишу свой деббагер! Работать он будет по схожему принципу, но будут существенные отличия - я не буду писать все в лог, а буду результаты отладки слать себе на почту. Бред? Возможно, но у меня есть пару козырных тузов. 1-ый, сколько времени вы тратите на открытие вкладки debug-log? Мне вообще не надо ничего открывать. 2-ое. Программисты – ленивые люди и порой, например, нам нужно просто узнать заходили ли мы в метод или нет, а не копаться в целой таблице отчета Debug-log. Скажу вам, очень удобно, когда мы заходим в метод – нам приходит письмо. 3-е. Вы можете продебажить установленные пакеты? Как слишком короткий лог? А я могу, мне все приходит на почту. Продебажил и вместо бэтты-версии – собралmanaged (unmanaged) версию и дело в шляпе.
Сравнение:
Old School: Открыть SF->В поиске набрать Debug log -> выбрать юзера -> запустить выполнение-> открыть лог -> найти строчку. (30сек -1 мин).
Мое решение: запустить выполнение -> получить письмо (10-20 сек).
Итого: В сутки можно сэкономить до 20-30 минут, например, на игру в любимый Mortal Combat.
Однако, как я и думал… не все так просто! Первая проблема, с которой столкнулся ваш покорный слуга – это треклятые лимиты. Лимиты на отправку почтовых голубей. 10 писем из одной точки входа, ну или если у вас там не developer-edition можете довольствоваться нечто большим. Казалось бы утопия, но нет. На помощь пришло решение от моего коллеги, который как-то проговорился о том, как они исправили проблему отправки писем по лимитам (можно было бы реализовать сервис, который отправлял письма клиентам в сутки более, чем 10 штук из точки входа, но я решил, что эта тема не нова). Я взял предложенный сервис и продолжил свои исследования и приготовления.
Рецепт:
Заходим на сайт mailgun.com. Регистрируем себя. Там просто обширная документация – почитайте. Для работы нам понадобитьсяhost и key, по которому мы будем связывать SF и mailgun. Также, зарегистрируйте свой Email-service, который будет высылать письма.
Salesforce.com; 90 строчек apex кода; mailgun.com; Custom setting (по вкусу, не обязательно); голова на плечах (обязательный компонент).
Итак, немного лирики и пояснения, что я хочу сделать:
- Сэкономить время девелопера на процесс деббагинга.
- Продебажить SF-пакеты.
- Показать преимущество и недостатки Debug-а для захудалого программиста в мире SF.
Что же столкнуло с места меня на столь дерзкий шаг, а именно тягаться с SF-овским деббагером? Признаюсь, новый проект, а точнее их россыпь. Мне дико не хватало времени все уследить и за все исправить. Плохой сон, переживания, и, наконец, прозрение одной ночью – я напишу свой деббагер! Работать он будет по схожему принципу, но будут существенные отличия - я не буду писать все в лог, а буду результаты отладки слать себе на почту. Бред? Возможно, но у меня есть пару козырных тузов. 1-ый, сколько времени вы тратите на открытие вкладки debug-log? Мне вообще не надо ничего открывать. 2-ое. Программисты – ленивые люди и порой, например, нам нужно просто узнать заходили ли мы в метод или нет, а не копаться в целой таблице отчета Debug-log. Скажу вам, очень удобно, когда мы заходим в метод – нам приходит письмо. 3-е. Вы можете продебажить установленные пакеты? Как слишком короткий лог? А я могу, мне все приходит на почту. Продебажил и вместо бэтты-версии – собралmanaged (unmanaged) версию и дело в шляпе.
Сравнение:
Old School: Открыть SF->В поиске набрать Debug log -> выбрать юзера -> запустить выполнение-> открыть лог -> найти строчку. (30сек -1 мин).
Мое решение: запустить выполнение -> получить письмо (10-20 сек).
Итого: В сутки можно сэкономить до 20-30 минут, например, на игру в любимый Mortal Combat.
Однако, как я и думал… не все так просто! Первая проблема, с которой столкнулся ваш покорный слуга – это треклятые лимиты. Лимиты на отправку почтовых голубей. 10 писем из одной точки входа, ну или если у вас там не developer-edition можете довольствоваться нечто большим. Казалось бы утопия, но нет. На помощь пришло решение от моего коллеги, который как-то проговорился о том, как они исправили проблему отправки писем по лимитам (можно было бы реализовать сервис, который отправлял письма клиентам в сутки более, чем 10 штук из точки входа, но я решил, что эта тема не нова). Я взял предложенный сервис и продолжил свои исследования и приготовления.
Рецепт:
Заходим на сайт mailgun.com. Регистрируем себя. Там просто обширная документация – почитайте. Для работы нам понадобитьсяhost и key, по которому мы будем связывать SF и mailgun. Также, зарегистрируйте свой Email-service, который будет высылать письма.
Суть в чем, я посылаю http request на сервис и получаю себе на почтувыстрел из пушки письмо. Получаем key. Далее создаем в SF (SecurityControls -> Remote Site Settings) привязку с mailgun.
Далее создаем свои custom setting. Нет, делать это не обязательно, но во-первых, мы пришли сюда ради эстетики, а во-вторых, любителям все захардкодить будет дано слово в комментариях.
Создаем дефолтные настройки. У вас будет нечто схожее, только keyбудет отличаться. Поле isDebug отвечает за работу дебага. Достаточно убрать переключатель и мы выключим к чертям все это безобразие.toAddress – адрес получателя дебаг лога. Обратите внимание наendpoint! После /v2/ ваш созданный сервис / messages.
Все начинаем заниматься начинкой для утки. Создаем класс. Сама реализация до безобразия проста. В основе лежит HttpRequest, который мы пошлем по endpoint’у mail.gun. Далее все сделает он за нас. Реализация программы – довольна проста. Я реализовал паттернSingleton, чтобы не дай бог не наплодить объектов своего детища (шучу). Основу работы составляют два метода. systemDebug и stopDebug. Первый отвечает за формирование объекта в лог, второй по сути за отсылку письма.
Для работы достаточно:
DebugLogUtil.getInstance().systemDebug(‘STR HELLO!’);
DebugLogUtil.getInstance().stopDebug();
Нет, можно конечно, хоть сотню systemDebug вызовов делать и потом одним stopDebug получить себе на почту пищу для размышления. А можно чередовать. Вообщем, что я говорю – код ниже на гит-хабе.
https://github.com/ArtemLevchenko/salesforce/tree/master
Ну и пару примеров.
Для работы достаточно:
DebugLogUtil.getInstance().systemDebug(‘STR HELLO!’);
DebugLogUtil.getInstance().stopDebug();
Нет, можно конечно, хоть сотню systemDebug вызовов делать и потом одним stopDebug получить себе на почту пищу для размышления. А можно чередовать. Вообщем, что я говорю – код ниже на гит-хабе.
https://github.com/ArtemLevchenko/salesforce/tree/master
Ну и пару примеров.
- List <Account> list2Account = new List <Account>();
- list2Account.add(new Account(Name = 'Test' ));
- list2Account.add(new Account (Name = 'Test2'));
- insert list2Account;
- DebugLogUtil.getInstance().systemDebug(list2Account);
- for(Account acc : list2Account){
- DebugLogUtil.getInstance().systemDebug(acc);
- }
- DebugLogUtil.getInstance().stopDebug();