2016-09-16 9 views
2

Мы внедрили сервис отдыха в управляемом пакете. Некоторые из наших клиентов уже установили этот пакет. В настоящее время он принимает 3 параметра. Целью является отправка обновлений, сделанных в одной системе, экземпляру Salesforce с установленным управляемым пакетом. При создании этой службы мы следовали примеры изложены здесь ... ..Salesforce REST API с управляемым пакетом

https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_rest_methods.htm

Мы хотим, чтобы добавить дополнительный параметр для нашего метода POST вызова. Например, перейдите от 3 параметров к 4. Мы хотим, чтобы это изменение было обратно совместимым. То, что мы видим при попытке проверить это, является ошибкой «Ресурс не найден» при отправке 4 параметров, а не старых 3 параметров.

Можно ли просто обновить код сервисного обслуживания без повторного подключения всех наших клиентов? Или кто-нибудь, кто установил управляемый пакет, должен выйти и получить новый пакет, чтобы прочитать новый параметр? Каков наилучший способ управления изменениями или обновлениями?

Есть ли более эффективная реализация или способ борьбы с подобным сценарием? Ответственность за определение установленной версии API/пакета несет ли кто-либо из участников и передает три или четыре параметра?

Если вы можете поделиться лучшими практиками по обновлению реализации метода REST API в salesforce, это действительно оценено.

Пример Старый Путь: ../apex/updateSomething послан с JSON в теле { "element1": "Значение1", "element2": "Value2", "element3": "Value3"}

Пример Новый способ: ../apex/updateЧто-то отправлено с json в теле {"Element1": "Value1", "Element2": "Value2", "Element3": "Value3", "Element4": "Value4"}

+0

Возможно, вы должны добавить некоторые примеры использования API (те, которые работают и которые не работают) – YakovL

ответ

0

Я вижу два разных вопроса, я попробую и обоим.

  1. «Должны ли они выходить и модернизировать себя?». Нет, они не могут, вы можете нажать обновление: https://developer.salesforce.com/docs/atlas.en-us.packagingGuide.meta/packagingGuide/push_upgrade_intro.htm
  2. «Как мы можем сделать это обратно совместимым?». Не можете ли вы сохранить старый метод для трех входных параметров и создать новый для четырех?

Труднее дать ответ без какого-либо конкретного кода.

0

Существуют различные способы достижения этого.

Первый вариант.
@RestResource(urlMapping = '/DemoEndpoint/v1/*')

Добавляя v1, ваши конечные пользователи могут использовать разные версии и обновляться до более новых версий при их готовности. Следующая версия может быть
@RestResource(urlMapping = '/DemoEndpoint/v2/*')

Версии являются рекомендуемыми для конечных точек API. Вам нужно будет создать отдельные классы для каждой версии.

Второй способ - изменить способ принятия входных параметров. В этом случае удалите входные параметры в определении метода и используйте Request.requestbody.

Это исходный код (если вы следовал руководство разработчика примеру)
@HttpPost global static void myPostMethod(string Element1, string Element2, string Element3, string Element4)

Нового код принимающего 3 или 4 параметра (или 0 параметров, смотрите примечание ниже).

@HttpPost 
global static string myPostMethod() { 
    RestRequest request = RestContext.request; 
    String body = request.requestBody.toString(); 
    List<Wrapper> obj = (List<Wrapper>) JSON.deserialize(body, List<Wrapper>.Class); 

Класс обертки будет

public class Wrapper{ 
    string Element1; 
    string Element2; 
    string Element3; 
    string Element4; 
} 

Если element4 пусто не было принято. Используя этот метод, вам нужно будет сделать проверку входных данных. Например, это будет принимать нулевые параметры, и все элементы будут пустыми.