Apex только для приложений, размещенных на сайте force.com?

Разрешен ли Apex только в «собственных» приложениях, размещенных на force.com?

Или Apex также доступен для внешних приложений, которые могут использовать «открытые API-интерфейсы», такие как REST API и Bulk API?

Я думаю, что отчасти моя путаница заключается в том, как термин «Rest API» используется в различных документах. В других частях мира программного обеспечения REST обычно означает протокол на основе HTTP для обмена данными между разными доменами (с определенными форматами и т. Д.). Тем не менее, я думаю, что Rest API в отделе продаж ИНОГДА может относиться к дополнительным средствам для нативных приложений для получения данных Salesforce из force.com. Это правильно?


person R Claven    schedule 30.05.2014    source источник


Ответы (1)


Не уверен, что понимаю ваш вопрос ...

Apex можно использовать «внутри» в:

  • триггеры базы данных,
  • classes
    • Visualforce controllers that follow MVC pattern,
    • логика, которая анализирует входящие электронные письма и, например, делает из них записи о делах или потенциальных клиентах,
    • асинхронные задания, которые можно запланировать для пересчета некоторых важных вещей каждую ночь
    • и у вас могут быть служебные классы для повторного использования кода в этих

«Внутренним» было бы использование механизма «Выполнить анонимно», который позволяет запускать разовые фрагменты кода для среды. Полезно для создания прототипов новых классов, исправлений данных и т. Д. Вы можете сделать это, например, в Eclipse IDE или консоли разработчика (верхний правый угол рядом с вашим именем).


И последнее, но не менее важное - «внешнее» использование.

Код Apex может быть представлен как веб-сервис и вызван приложениями PHP, .NET, Java и даже JavaScript. Это хороший выбор, когда:

  • вы хотите повторно использовать один и тот же фрагмент логики, например, на своей собственной странице Visualforce, а также в каком-либо мобильном приложении, которое будет передавать пару строк или простой объект JSON
  • лучше, чем необходимость заново реализовывать логику в каждом новом приложении и поддерживать ее впоследствии.
  • представьте, как вставить учетную запись и контакт за один раз - ваше мобильное устройство должно будет реализовать некоторый контроль транзакций и удалить учетную запись, если контакт не загрузился. Грязный. И будет тратить больше вызовов API (вставить acc, вставить con, ooops, удалить acc). С помощью метода, представленного как веб-сервис, вы можете принять оба параметра в свой код Apex, творить чудеса и хорошо, если он не удастся - все в одной транзакции, поэтому SF откатит его для вас.

Есть 2 основных метода:

  • SOAP API в основном использует глобальные методы, отмеченные ключевым словом webservice. Самый простой способ для других приложений начать их вызывать - это извлечь из SF и «использовать» так называемый «корпоративный WSDL-файл». Это гигантский XML-файл, который можно проанализировать в вашем .NET-приложении для генерации кода, который поможет вам написать код, с которым вы знакомы. Эти сгенерированные классы будут создавать для вас XML-сообщение, отправлять его, обрабатывать ответ (генерировать собственные исключения, если SF отправил сообщение об ошибке) и так далее.

Очень простой пример:

global class MyWebService {
    webService static Id makeContact(String lastName, Account a) {
        Contact c = new Contact(lastName = 'Weissman', AccountId = a.Id);
        insert c;
        return c.id;
    }
}
  • REST API позволяет делать аналогичные вещи, но вам нужно использовать правильные HTTP-команды («PUT» лучше всего подходит для вставок, «PATCH» для обновлений »,« DELETE »и т. д.).

Подробнее о них можно прочитать в руководстве по REST API: http://www.salesforce.com/us/developer/docs/apexcode/index_Left.htm#CSHID=apex_rest_methods.htm|StartTopic=Content%2Fapex_rest_methods.htm|SkinName=webhelp

person eyescream    schedule 31.05.2014
comment
Большое спасибо за то, что нашли время. Когда я задал этот вопрос, я все еще тонул в маркетинговых материалах, но это помогло! - person R Claven; 23.07.2014
comment
да я должен был давно :( - person R Claven; 23.07.2014