Можно ли передавать security token как URL параметр?

сторонний вопрос, почему написать email-listeners проще чем Web-service ?

сохрани свой токен как label или как hierarchy custom setting , и к тому и к тому есть доступ напрямую из вижуалфорса

https://developer.salesforce.com/docs/atlas.en-us.pages.meta/pages/pages_variables_global_setup.htm

[quote="Андрей"]сохрани свой токен как label или как hierarchy custom setting , и к тому и к тому есть доступ напрямую из вижуалфорса[/quote]
Если я правильно понял, [b]Den Brown[/b] хочет просто выставить в интернет VF страницу, которая будет использоваться как интеграция. Т.е. get'нул эту VF страницу - у тебя создались записи в СФ.

[b]Den Brown[/b], главный вопрос - почему нельзя использовать другие, более правильные методы интеграции? Webservice, REST API етц? Если вопрос только в сложности, то, как по мне, создать ВФ страницу и заэкспоузить ее наружу выглядит в разы сложнее, чем написать веб сервис.
Если по каким-то причинам все-таки нужна VF page - то я бы использовал хотя бы public key передаваемый через URL параметр. Хотя бы защита от того, что кто-то левый не зайдет на сайт и не завалит орг кривыми данными.

[quote="EvAzi"]Если я правильно понял, Den Brown хочет просто выставить в интернет VF страницу, которая будет использоваться как интеграция. Т.е. get'нул эту VF страницу - у тебя создались записи в СФ.[/quote]

правильно, и в боди страница вернула какую то инфу

[quote="EvAzi"]почему нельзя использовать другие, более правильные методы интеграции? Webservice, REST API етц?[/quote]

можно, я уже начинаю склонятся в эту сторону. Но поднять, например, кастомный SOAP сервис - это одна сторона вопроса, кроме этого еще нужно помочь другим людям (на стороне легаси приложения) написать для него клиент, а в нем обязательно должна быть авторизация... не знаю стоит ли со всем этим связываться для временной интеграции...  но вероятно придется

[quote="Андрей"]почему написать email-listeners проще чем Web-service ?[/quote]
я помню старо-давние времена, когда СФ рекомендовал во всех случаях где возможно использовать email-listeners-based интеграцию, как самый простой способ (плюс Outbound messages). Сейчас они уже так не говорят, но вариант остался

в реальности требования довольно странные и вероятно основаны на непонимании заказчика как (сложно) это все работает. Есть две паралельные ситуации:
(1) легаси приложение которое имеет WS client to third-party платежному WS service. И third-party платежный WS service меняет то ли формат, то ли протокол своего WS service, в результате чего существующая интеграция с легаси приложением через полгода перестанет работать. 
(2) паралельно мы начинаем работу по миграции легаси приложение на СФ платформу, и в новом приложении мы сделаем новый WS client to third-party WS service, который уже будет в новом форме и все ок.

Но не долго музыка играла! Внезапно клиент хочет, чтоб мы  помогли им поддержать интеграцию между   легаси приложением и third-party WS service на какое-то время. При этом они по неведомым причинам не хотят просто запилить новый WS client на легаси приложении чтоб он продолжил работу с third-party  WS service, а хотят использовать СФ орг как посредник в процессе, т.е. нужна интеграция между легаси и СФ оргом, возможно в виде веб-сервиса:
- легаси имеет WS client к нашему новому кастомному WS service который в свою очередь вызывает WS client to third-party WS service. Звучит сложно, и сделать это еще сложнее: принять WS client call от легаси, сделать call to third-party WS service, получить от него response, и переправить его как response в легаси. Получится ли вообще это сделать синхронно? а если делать несинронно, то email-listrner-based integration выглядит проще для меня

чет не совсем понятно. SOAP или REST используется. Ладно еще с SOAP понятно что сложновато, потому что не каждый день используется и надо в доках покопаться, но REST Web Service открыть на стороне SF это ж 10 минут работы копипаста 10 строк. "email-listrner-based integration" - что? первый раз вообще про такую слышу, и когда она была рекомендованной? Понимаю сделать Email Listener когда надо работать с Emails (принимать их) но делать на Emails интеграцию? Не кажется что предназначение Emails немного в другом? И вообще кто вам гарантирует что ваши Emails 100% дойдут куда надо? Для этого и существует REST. И ничего в нем сложного нет. Придумываем красивый endpoint, создаем Apex Class где прописываем REST Web Service и ждем когда придут запросы. 

Теоретически пересылать запросы через SF можно как временное решение, но нужно быть готовым к различного рода проблемам, так как обычная прямая связь растягивается уже по цепочке на несколько систем и ХЗ где может упасть. Отлаживать такие системы уже будет сложно. (Надо кстати еще проверить можно ли послать HTTP Callout из WebService). И вот тут самое интересное - с Email Listener такое уже хрен провернешь.

На счет RESTfull VF + SecurityToken. Тут раельно гемору по сравнению с обычным REST Web Service получится в разы больше. ПОтому что, во-первых надо страницу прокинуть в открытый доступ, а это надо гемороиться с настроками сайта, открывать страницу, права Site Guest User надо учитывать, пилить свою систему авторизации, на том же token.

И наконец, ответ на самый основной вопрос темы - "Можно ли передавать security token как URL параметр?". А какая разница как ты передаешь свой security token - в headers, в POST body, в GET параметре. Один фиг где бы он не лежал он находится в тебе запроса. Другой дело чтобы ты не постил такие ссылки (с security token) куда-то на Facebook или в Одноклассники :D Тогда реально будет косяк :D 

[quote="Dmitry Shnyrev"]нужно быть готовым к различного рода проблемам, так как обычная прямая связь растягивается уже по цепочке на несколько систем и ХЗ где может упасть. Отлаживать такие системы уже будет сложно. [/quote]

вот это пытаюсь им объяснить

а так, согласен с вами, проще запилить интеграцию на основе REST Web Service и пусть интегрируются

правда остается вопрос

[quote="Dmitry Shnyrev"] можно ли послать HTTP Callout из WebService[/quote]

[quote="Den Brown"]правда остается вопрос


Dmitry Shnyrev
можно ли послать HTTP Callout из WebService[/quote]

Ну это же легко проверить ;) 

[quote="Dmitry Shnyrev"]Ну это же легко проверить [/quote]

сначала погуглю :)

[quote="Den Brown"]я помню старо-давние времена, когда СФ рекомендовал во всех случаях где возможно использовать email-listeners-based интеграцию, как самый простой способ (плюс Outbound messages). [/quote]

скорее всего я ошибаюсь, спутав с вот этой фразой:

[i]Use outbound messaging to handle integration solutions when possible. Use callouts to third-party web services only when necessary.[/i]

[quote="Dmitry Shnyrev"]Ну это же легко проверить [/quote]

проверил, вот этот код работает:

[code]
@RestResource(urlMapping='/Calculator/*')
global with sharing class REST_Calculator_WS {
    
    @HttpPost
    global static Double doAdd(String firstNumber, String secondNumber) {

        Double x = Double.valueOf(firstNumber);
        Double y = Double.valueOf(secondNumber);       
        
        // callout to SOAP WS
        calculatorServices.CalculatorImplPort calculator = new  calculatorServices.CalculatorImplPort();

        Double result = calculator.doAdd(x,y);
        System.debug(result);
        
        return result;
    }
}

[/code]

стукнул ПОСТ в Workbench, приходит результат

Ну вот и отлично! Клиент спасен от страшных костылей :D