Создаем первый Managed package: советы бывалых для новичков

[quote="Den Brown"]

ну а я начну с самых простых вопросов:
- Managed package можно создавать только в пределах Дев Орга (никак не в сендбоксе)?
- при попытке активировать Managed package в Дев Орге, система просит назначит Префикс- для кода. После того как я его назначу, он "прилипнет" [b]абсолютно ко всем[/b] классам, тригерам в Орге, и возможно даже к метадате?
[/quote]
1. Да
2. Да, и к метадате тоже, поменять потом нельзя, префикс уникален для всего Salesforce. 
От себя, разработка Managed Package это местами та еще задница, главным образом потому, что это package ставится в org, о котором вы ничего не знаете и никак не контролируете. 
Основные источники знаний по Managed Package: [url=https://help.salesforce.com/help/pdfs/en/salesforce_packaging_guide.pdf]ISV Guide[/url]
[url=http://www.amazon.com/Force-com-Enterprise-Architecture-Andrew-Fawcett/dp/1782172998]Force.com Enterprise Architecture[/url]

Если есть Js который работает с датой,то префиксы ко всем полям придется прописывать ручками.

А вообще не так все страшно. Дорогу осилит идущий.

Публикая пакета это да. Та еще песня.

Спасибо Mike за помощь.

[quote="Mike V"]2. Да, и к метадате тоже, поменять потом нельзя, префикс уникален для всего Salesforce. 
[/quote]
ОК, тот префикс, который я указываю при активации managed package (МП), он "прилипнет" только к компонентам в МП-ах, или ко всей метадате в том Орге?

[quote="Mike V"]
От себя, разработка Managed Package это местами та еще задница, главным образом потому, что это package ставится в org, о котором вы ничего не знаете и никак не контролируете. 
[/quote]
По-этому поводу нет никаких сомнений. 
Как я понимаю, в "продуктовой" конторе большая часть работы для разрабов заключается в том, чтобы выяснить почему МП не работает  как должен в клиентском Орге, а также в кастомизации Приложения для конкретного клиента.
И вот здесь я не понимаю, как это можно сделать с МП. В СФ написано, что МП работает по принципу distribution-by-reference (не distribution-by-copy, как unmanaged package (UMP)), т.е. одни код на всех клиентов.
А если так, то как его кастомизировать под конкретного клиента?

[quote="Mike V"]Force.com Enterprise Architecture[/quote]
спасибо за наводку

[quote="wilder"]Дорогу осилит идущий.[/quote]
один из моих учителей в таких ситуациях говорил мне: воспринимай это как тренинг.

Еще вопрос, не могу еще понять, есть ли разница в переносе метадаты между двумя Оргами с помощью Анта (а также Эклипса) и с помощью unmanaged package? 

[quote="wilder"]Если есть Js который работает с датой,то префиксы ко всем полям придется прописывать ручками.[/quote]
Разве? Ни разу не прописывал, хотя полпакета на JS написано.
Можешь немного подробнее описать пример, чтобы подискутировать на эту тему.

Вот пример :

[code]
var getItems = function (id) {
var SOQL = "SELECT Id, Name, [b]Project__r[/b].Name " + (id != null ? ', Article__c' : '') + " FROM Wiki__c WHERE Type__c='" + type + "'" + (id !=null ? " AND id = '" + id + "'" : '') + ' ORDER BY CreatedDate Desc';

var result = sforce.connection.query(SOQL).getArray("records");
return result;
}
[/code]

Для нормальной работы в пакете нужно прописать префиксы о всем кастомным полям и объектам

[code]
var SOQL = "SELECT Id, Name, [b]ssync.Project__r[/b].Name " + (id != null ? ', ssync.Article__c' : '') + " FROM ssync.Wiki__c WHERE ssync.Type__c='" + type + "'" + (id !=null ? " AND id = '" + id + "'" : '') + ' ORDER BY CreatedDate Desc';[/code]

[quote="Den Brown"]ОК, тот префикс, который я указываю при активации managed package (МП), он "прилипнет" только к компонентам в МП-ах, или ко всей метадате в том Орге?[/quote]

Если правильно помню, то только к метадате, что добавлена в пакет. И поэтому бывают проблемы с новым функционалом, который еще не добавлен в пакет.

[quote="Den Brown"]Еще вопрос, не могу еще понять, есть ли разница в переносе метадаты между двумя Оргами с помощью Анта (а также Эклипса) и с помощью unmanaged package?[/quote]

Как по мне это одно и тоже.

[quote="Den Brown"]А если так, то как его кастомизировать под конкретного клиента?[/quote]

Пишется extension для конкретного клиента. 

От себя немного.
Префикс добавляется к данным управляемого пакета.
Второе - обратил бы внимание (сам наступал) на видимость методов и переменных. Нельзя будет сменить видимость с global на public.

[quote="wilder"]ssync.Project__r.Name[/quote]
Подожди, разве так пишется префикс к полям и объектам?
не [b]ssync__Project__r.Name[/b]

И второй вопрос - у тебя JS выполняется в контексте Visualforce страницы?

[quote="ogoblin"]Нельзя будет сменить видимость с global на public[/quote]
Это самый большой бич всех пакетов. 30 раз подумай прежде чем что-то объявлять Global. Для этого случая даже целые паттерны проектирования выдумываются.

[quote="Dmitry Shnyrev"]И второй вопрос - у тебя JS выполняется в контексте Visualforce страницы?[/quote]
да

[quote="Dmitry Shnyrev"]ssync__Project__r.Name[/quote] 

Вот тут мой косяк, перепутал с вызовом метода.

спасибо всем.

[quote="ogoblin"]Нельзя будет сменить видимость с global на public[/quote]

а в каких ситуациях может возникнуть такая необходимость?


также еще вопрос: если я все правильно понял, для Managed Package нет абсолютно никакого применения, кроме как в Листинге на AppExchange?

[quote="wilder"]Вот тут мой косяк, перепутал с вызовом метода.[/quote]
Не проблема, просто уточнил.

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

{!$ObjectType.SomeCustomObject__c.name}
{!$ObjectType.SomeCustomObject__c.fields.SomeCustomField__c.name}

Вроде еще можно делать
{!$ObjectType.SomeCustomObject__c.fields.SomeCustomField__c.relationshipName}
но не могу найти сейчас в исходниках, чтобы сказать наверняка.

Эта фигня отлично выручает во всех случаях - и с префиксами и без префиксов.
И больше того, когда префиксов много :D - у нас кстати такая интересная dev архитектура - что у каждого дева свои префиксы на дев оргах, а меняются они при деплое в ант. В общем в нашем случае воообще ни о каких хардкодных префиксах речи быть не должно. Пакет большой, кода много, отлично без хардкодных префиксов справляемся.

[quote="Den Brown"]а в каких ситуациях может возникнуть такая необходимость?[/quote]
Когда хотели сначала сделать какой-то класс глобальным==доступным извне, но потом передумали. Такой класс, ни объявления методов внутри уже поменять нельзя. Можно только поставить deprecated, но все равно мусор в пакете останется.

[quote="Den Brown"]также еще вопрос: если я все правильно понял, для Managed Package нет абсолютно никакого применения, кроме как в Листинге на AppExchange?[/quote]
Почему? Managed packages отлично без AppExchange обходятся - это всего лишь маркет, но пакеты можно и вручную распространять. А главная цель - спрятать свой код от чужих глаз. Все что внутри Managed Package не доступно извне после установке на другой орг (кроме собственно глобальных классов и методов).

[quote="Dmitry Shnyrev"]{!$ObjectType.SomeCustomObject__c.name} [/quote]

Сорри, не правильно тебя понял. Контекст не VP, поэтому твой способ не прокатывает.

[quote="Dmitry Shnyrev"]Почему? Managed packages отлично без AppExchange обходятся - это всего лишь маркет, но пакеты можно и вручную распространять. [/quote]

Вот тут ты не совсем прав. На Group, Professional Edition ты можешь поставить пакет, только с маркета.

А что ж там за пакеты такие можно поставить на эти типы оргов?

[quote="wilder"]Сорри, не правильно тебя понял. Контекст не VP, поэтому твой способ не прокатывает.[/quote]
А вот тут новый вопрос :) А почему контекст не на VF (я кстати тоже не совсем верно выразился про контекст, конечно не контекст выполнения, а место расположение исходного кода). Понимаю что вокруг только и примеры что нужно делать красивую кучу JS файлов, засовывать их в статик ресурсы. 
Как по мне все это фигня. Отлично JS располагается в пределах одного файла (той же VF страницы), отлично редактируется, отлично ему доступны все возможности VF при инициализации. У меня уже куча примеров таких одностраничных приложений партянок. Даже целый call-центр в одну страницу уложил, было дело.

[quote="Dmitry Shnyrev"]А что ж там за пакеты такие можно поставить на эти типы оргов?[/quote]

Любые, но только с маркета.

JS крутиться на custom button, на standard layout.

[quote="Dmitry Shnyrev"]Понимаю что вокруг только и примеры что нужно делать красивую кучу JS файлов, засовывать их в статик ресурсы. [/quote]

ха,ха, а я и никогда не думал об этом: если вывести JS код в отдельный файл, то он уже живет своей собственной судьбой, и {!$VF-переменные} в нем уже недоступны

[quote="Den Brown"][quote="Dmitry Shnyrev"]Понимаю что вокруг только и примеры что нужно делать красивую кучу JS файлов, засовывать их в статик ресурсы. [/quote]

ха,ха, а я и никогда не думал об этом: если вывести JS код в отдельный файл, то он уже живет своей собственной судьбой, и {!$VF-переменные} в нем уже недоступны[/quote]

Ну на самом деле это не большая проблема. Создавай класс и передавай туда {!$VF-переменные} как параметры. И тогда будет не так важно откуда этот код будет вызываться.

[quote="wilder"]Ну на самом деле это не большая проблема. Создавай класс и передавай туда {!$VF-переменные} как параметры. И тогда будет не так важно откуда этот код будет вызываться.[/quote]

не понял, как это?

ведь JS выведенный в отдельный файл подгружается на клиенте как стат ресурс, как, например, картинка. указать в нем, например, переменную из контроллера можно {!MyVar} - но это будет просто текст, в реальное значение он никогда не превратиться...

[quote="Den Brown"][quote="wilder"]Ну на самом деле это не большая проблема. Создавай класс и передавай туда {!$VF-переменные} как параметры. И тогда будет не так важно откуда этот код будет вызываться.[/quote]

не понял, как это?

ведь JS выведенный в отдельный файл подгружается на клиенте как стат ресурс, как, например, картинка. указать в нем, например, переменную из контроллера можно {!MyVar} - но это будет просто текст, в реальное значение он никогда не превратиться...[/quote]

Ну строго говоря всегда есть трики.

1. var fromVF = eval("{!MyVar}"); не люблю это, но иногда использую
2. var fromVF = JSON.parse("{!myVar}") - ну это если ты имеешь дело с JSON

а класс достаточно просто пишется.
[code]
var testClass = function(a,b) {
}

var a = eval("{!MyVar}");
var b = eval("{!MyVar1}");

var testClassEx = new testClass(a,b);
[/code]

Ну как-то так.

Поддерживаю способ с JSON - постоянно использую, когда лень гонять данные через remote action

правда правильнее будет так писать

var fromVF = JSON.parse("{!JSENCODE(myVar)}")

а то кавычки внутри JSON быстро положат JS.

В чем прелесть такого подхода - в контроллере создаешь переменную с геттером сколь угодно сложным (структура данных может быть какой угодно - сложные DTO, куча вложенных мапов), а последняя строчка будет

return JSON.serialize(superMagePuperComplexData);

а на самой странице в JS после строчки выше это все развернется в красивый объект со всей необходимой иерархией, доступ к которому можно выполнять через "."

[quote="wilder"]Вот тут ты не совсем прав. На Group, Professional Edition ты можешь поставить пакет, только с маркета.[/quote]
А вот тут ты не прав))

[quote="Gres"]А вот тут ты не прав))[/quote]

Сделай плиз видео как ты ставишь пакет на Group Edition из своего деворга :)

[quote="wilder"]Сделай плиз видео как ты ставишь пакет на Group Edition из своего деворга :)[/quote]
Только 1 уточнение из Dev орга партнера

Итак, управляемый пакет позволяет скрыть содержимое кода и ВФ компонентов, а также, являясь distribution by reference, дает возможность более простого обновления кода: обновил в одном месте, обновилось везде. Но, в связи с этим свойством, сложнее делать клиентскую кастомизацию.

И ситуация: есть Приложение, которое руководство хочет обобщий и использовать для других проектов, т.е. сделать такой "внутренний" продукт. Я делаю всю эту работу в Дев Орге (его кстати можно позже превратить в Партнерский Дев Орг?) и все готово. И вот нашелся Проект в отдельном Enterprise Орге, который требует данный функционал.

И вопрос: как задвинуть наше Придложение в новый Орг: в виде управляемого пакета или как обычно, то есть скопировать с помощью Анта или неуравляемого пакета?
есть ли у  управляемого пакета в таком случае (собственное использование Приложение, возможно многократное в разных Оргах) какое то очевидное преимущество? или нечего мудрить, просто копирую?

[quote="Den Brown"]обновил в одном месте, обновилось везде[/quote]
Нет такого. Есть обновил пакет - обновлять на стороне клиента нужно вручную, в смысле запускать апдейт пакета.

[quote="Den Brown"]Но, в связи с этим свойством, сложнее делать клиентскую кастомизацию.[/quote]
Не сложно, просто пакет должен предусматривать кастомизацию архитектурно. Кастомизация это обычно unmanaged code на клиентском орге где установлен пакет, а следовательно на него распространяются правила безопасности пакета, т.е. доступ к функционалу пакета можно получить только на уровне глобальных методов.

[quote="Den Brown"]есть ли у управляемого пакета в таком случае какое то очевидное преимущество? или нечего мудрить, просто копирую?[/quote]
Если орги "свои", то нечего заморачиваться с пакетами. Если не хочется чтобы клиент видел код, менял (aka ломал) его, поддерживалась версионность, легкая процедура обновления, то однозначно managed package. 

Хотя нет, все-таки в любом случае при необходимости установке на другие орги в любом случае стоит использовать package. Все-таки это отдельный namespace и гарантия того что не будет совпадения по именам (авось затрешь клиентскую часть функционала только потому что она имеет тоже имя).

[quote="Dmitry Shnyrev"] стоит использовать package.[/quote]

какой пакедж? или это сравнение между пакедж и вариантом просто задвинуть код с помошью Анта, например?

[quote="Den Brown"]сравнение между пакедж и вариантом просто задвинуть код с помошью Анта[/quote]
Да я это подразумевал.

Но в принципе есть еще unmanaged package, правда особой выгоды его использования пока не видел.

[quote="Dmitry Shnyrev"][quote="Den Brown"]сравнение между пакедж и вариантом просто задвинуть код с помошью Анта[/quote]
Да я это подразумевал.

Но в принципе есть еще unmanaged package, правда особой выгоды его использования пока не видел.[/quote]

В использовании разницы нет. В распостранении есть. Согласитесь что не все могут залить исходники через ант или через эклипс. Поставить пакет значительно проще.

[quote="wilder"] Поставить пакет значительно проще.[/quote]
Объсняя своим, я говорю, что unmanaged package - это как Change set, но только работает между любыми Оргами...

а смысл переноса метадаты через локальную машину - в том, что ты можешь подправть ее в момент переноса, сменить названия, даже АПИ имена...

но все хотят управляемый пакет, так как полагают что это путь на АппЭксчендж. Так то так, но нужет ли он для использорвание Приложения как "внутренний" продукт, это все еще вопрос для меня...

[quote="Gres"]Только 1 уточнение из Dev орга партнера[/quote]
Последний раз когда я смотрел, поставить в PE можно было только managed package прошедший security review и имеющий какое-то там aloha application, единственное куда можно было поставить без всего этого это в специальный PE org, полученный через partner portal. 

[quote="wilder"][quote="Dmitry Shnyrev"][quote="Den Brown"]сравнение между пакедж и вариантом просто задвинуть код с помошью Анта[/quote]
Да я это подразумевал.

Но в принципе есть еще unmanaged package, правда особой выгоды его использования пока не видел.[/quote]

В использовании разницы нет. В распостранении есть. Согласитесь что не все могут залить исходники через ант или через эклипс. Поставить пакет значительно проще.[/quote]
И в использовании есть разница, тема уже поднималась, на вскидку - внутри managed package свои лимиты, что увеличивает суммарные лимиты.

[quote="Dmitry Shnyrev"][quote="Den Brown"]обновил в одном месте, обновилось везде[/quote]
Нет такого. Есть обновил пакет - обновлять на стороне клиента нужно вручную, в смысле запускать апдейт пакета.[/quote]

Вообще-то есть, называется "push upgrade", но там какие-то аццкие муки надо пройти (как минимум security review) чтобы тебе разрешили такое делать.
[quote="Den Brown"]есть ли у управляемого пакета в таком случае (собственное использование Приложение, возможно многократное в разных Оргах) какое то очевидное преимущество? или нечего мудрить, просто копирую?[/quote]
Да, преимущество по лимитам - смотри выше.
[quote="Den Brown"]Еще вопрос, не могу еще понять, есть ли разница в переносе метадаты между двумя Оргами с помощью Анта (а также Эклипса) и с помощью unmanaged package? [/quote]
Если единоразово - особой разницы нет, кроме того что либо по задумке, либо по баго-фиче, при деплое unmanaged package запускаются тесты которые идут в деплое :) Если многоразово - unmanaged package не проканает, потому что при попытке накатить его сверху тебе сообщат что такой фортель не пройдёт, шли бы вы отсюда или удалите unmanaged package который стоял раньше, в общем по простому - при помощи unmanaged package ты не сможешь ничего проапдейтить... только новое.[quote="wilder"]    ОК, тот префикс, который я указываю при активации managed package (МП), он "прилипнет" только к компонентам в МП-ах, или ко всей метадате в том Орге?

Если правильно помню, то только к метадате, что добавлена в пакет. И поэтому бывают проблемы с новым функционалом, который еще не добавлен в пакет.[/quote]
Префикс прилипает ко всей метадате в организации, единственное что есть такое понятие как Local Name, т.е. внутри самого пакета, равно как и в dev организации, где этот пакет разрабатывается, можно эти префиксы спокойно опустить, главное следить за порядком разименования переменных и всякими там затенениями.

Вроде по всем комментам пробежался, если что - спрашивай!

Кстати вспомнил очень интересный момент про пакеты (поправьте если что не так сказал, давно было).
Когда пакуешь пакет, можно выбрать бета или релиз. С релизом все понятно, все пользуются, а вот с бетой есть один существенный нюанс - ее нельзя обновить, можно только снести и поставить новый релиз или другую бету.
Был такой случай в начале моей карьеры, когда я занимался сбором пакетов, установкой их на тестовый орг и запуском тестов (тогда (да и сейчас наверное) про CI в той фирме ничего не знали). Так вот орг был какой-то большой сандбокс какой-то фирмы, ставились на него наверное зависимых пакетов 5. 
Все это красиво работало на релизах, пока не пришел я :D, не собрал беты и не поставил на этот сандбокс. Обновить установленные беты на этом сандбоксе уже не получилось, потому что надо было сносить пакеты полностью. Удалить из-за кучи связанных пакетов + еще кучи unmanaged кода завязанного на эти пакеты + кучи тестовых данных не представлялось возможным. В общем я убил таким образом боевой сандбокс заказчика :). Меня тогда сильно не ругали, из-за неопытности и наверное больше досталось лидам, которые не проследили (хотя я честно спрашивал и мне честно посоветовали выбрать бету).
Вот такой урок на своих ошибках.

Единственное предназначение беты, которое правда никогда мною не использовалось, да и не встречал - включенные в бету, но ещё не включенные в релизную версию, компоненты могут быть потом из пэкаджа удалены.

пробую сейчас, впервые, двигать целое приложение с помощью Анта с помощью "deployUnpackaged" в стандартный дев Орг.

И деплой фейлиться, мол  страницам не хватает контроллеров и компонентов. но я все включил в пакет загрузки.

хотя постойте, unit test лег по причине отсутствия вспомогательного класса. а что без покрытия классы не проходят в простой Дев орг?

PS: постепенно все ошибки с классами "рассосались"

осталось несколько мелких, среди них самая загадочная вот эта:
[i]layouts/Survey__c-Survey Layout.layout -- Error: The page 'ЭтоМояСпецСтраницаИспользумаяКакКомпонентНаСтандЛейаутеSurvey' does not use the standard controller: Survey__c, it uses: null[/i]

и еще странная вешь. выгрузил email template c именем HELLO/Request_Email
он выгрузился прямо "в папке" HELLO
а когда пытаюсь его задеплоить, то получаю:
email/HELLO/Request_Email.email -- Error: Cannot find folder:HELLO
вот это действительно не понятно в чем проблема...
где не может найти эту папку? в destination Орге, где еще. Но как ее там создать, только ручками?

[quote="Den Brown"]email/HELLO/Request_Email.email -- Error: Cannot find folder:HELLO [/quote]

У тебя скорее всего не хватает xml файла для описания папки hello.

[quote="Den Brown"]layouts/Survey__c-Survey Layout.layout -- Error: The page 'ЭтоМояСпецСтраницаИспользумаяКакКомпонентНаСтандЛейаутеSurvey' does not use the standard controller: Survey__c, it uses: null[/quote]

Вероятно на лайауте есть страница, которая не включена в деплой или есть ошибка на этой странице.

[quote="wilder"]У тебя скорее всего не хватает xml файла для описания папки hello.[/quote]

ok, здесь нужна помощь.
вот я нашел:
https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_folder.htm

я могу в описание компонента емейлТемплейт включить строку с папкой вот так:
    <types>
        [b]<members>sampleFolder</members>[/b]
        <members>sampleFolder/TestDocument.txt</members>
        <name>Document</name>
    </types>

но это ничего не меняет, так как я не могу понять куда включить\положить вот этот файл:

<?xml version="1.0" encoding="UTF-8"?>
<DocumentFolder xmlns="http://soap.sforce.com/2006/04/metadata">
    <accessType>Public</accessType>
    <name>sampleFolder</name>
    <publicFolderAccess>ReadWrite</publicFolderAccess>
</DocumentFolder>

Пора воскресить эту тему. :)

Вот хочу и я запилить своё приложение и пустить его в Аппэксчейнж. 
Как понимаю меня ждет безудержное весель?

Хотел бы узнать у бывалых такие вопросы:
- сколько времени может уйти на этот процесс?
- какие особенности для самого кода кроме глобал и паблик, и можно подробнее если эти классы будут статик?
- к чему сразу нужно готовиться, какие могут быть подводные камни?
- какие требования для кастом обджектов входящих в пакет?
- какие моменты можно придумать, чтобы ограничить триальную версию в функциональности? FMA?

Пока вроде всё :D

Уже много полезных советов написано выше.
Security Review может взять как минимум месяц, включая перепипску с security team.

Если пакет будет не Free, то надо приготовить 2700$  :-)

Из опыта, на custom object, который добавляешь в пакет, добавь поле AutoNumber.
В начале скорей всего в нём нет надобности, но после того как пакет будет MП и установлет, добавить уже будет нельзя.

[quote="Eric"]Уже много полезных советов написано выше.
Security Review может взять как минимум месяц, включая перепипску с security team.

Если пакет будет не Free, то надо приготовить 2700$  :-)

Из опыта, на custom object, который добавляешь в пакет, добавь поле AutoNumber.
В начале скорей всего в нём нет надобности, но после того как пакет будет MП и установлет, добавить уже будет нельзя.[/quote]

Спасибо за совет.
А 2700 для чего? в чем сия цель? - с этим уже разобрался. цена за секьюрети ревью
Плюс AutoNumber длявсех объектов или только там где это возможно будет нужно?

Вопрос в тему. 
У меня есть приложение, будет оно бесплатным для ползователй, однако оно взаимодействует с платными сервисами. Сервисы не пренадлежат мне. 
В таком случае нужно ли мне платить 2700 за ревью и будет ли оно бесплатным согласно политике СФ?

Был такой-же вопрос года 4 назад у одного клиента (правда сервис платный был его). 
Сказали что надо размещение приложения в AppExchange будет платным, даже несмотря на то что само оно представлялось как бесплатное.

[quote="Dmitry Shnyrev"]Был такой-же вопрос года 4 назад у одного клиента (правда сервис платный был его). 
Сказали что надо размещение приложения в AppExchange будет платным, даже несмотря на то что само оно представлялось как бесплатное.[/quote]
да но тут-то вся фишня что сервис не наш... вот тут то и вся хитрость.

Ну хитрость не хитрость, а важно с какой стороны посмотреть.
SF понять можно - приложение стимулирует пользователей регаться и платить кому-то левому. Почему SF должен с этого терять потенциальный доход?
А на счет "наш не наш" сервис. Очень отлично помню как надо было на секюрити ревью доказывать почему API от Paypal или Google не проходят секюрити ревью. Как будто они наши :D 

[quote="Dmitry Shnyrev"]Ну хитрость не хитрость, а важно с какой стороны посмотреть.
SF понять можно - приложение стимулирует пользователей регаться и платить кому-то левому. Почему SF должен с этого терять потенциальный доход?
А на счет "наш не наш" сервис. Очень отлично помню как надо было на секюрити ревью доказывать почему API от Paypal или Google не проходят секюрити ревью. Как будто они наши :D[/quote]
Согласен. То есть попытаться можно, но не факт что что-то может получиться?

Есть такая штука как лимита для пакета так и лимиты общие для орга, я бы послдение потестил на всякий случай...

[quote="Sergey Prishchepa"]Есть такая штука как лимита для пакета так и лимиты общие для орга, я бы послдение потестил на всякий случай...[/quote]
Сегодня почитал про деплой приложения. 
Там не просто так, там репорты прикрепить надо, логины пароли если ты взаимодействуешь с сторонними сервисами.
Веселье, если одним словом описать этот процесс.

А то!
Да, там будут смотреть не только твое приложение на безопасность, но еще и сторонний сервис.
Я почему выше упоминал про Paypal и Google :D
Потому что по условию Security Review ты должен еще и их просканировать и предоставить отчет об их безопасности и в случае проблем - устранить!
Про все остальные менее известные сервисы и API я вообще молчу :D 

[quote="Dmitry Shnyrev"]А то!
Да, там будут смотреть не только твое приложение на безопасность, но еще и сторонний сервис.
Я почему выше упоминал про Paypal и Google :D
Потому что по условию Security Review ты должен еще и их просканировать и предоставить отчет об их безопасности и в случае проблем - устранить!
Про все остальные менее известные сервисы и API я вообще молчу :D[/quote]

а чем их сканировать? 

Как я понимаю чтобы выложить приложение, нужно как минимум ежа против шерсти родить? и то не факт что после родов приложение заапрувят.

Я последний раз сталкивался с ревью 3 года назад. 
Возможно что-то поменялось, не хочу врать.
Вот тут по ссылке https://developer.salesforce.com/page/Security_Review
упоминаются
https://security.secure.force.com/security/tools/webapp/zapbrowsersetup
https://developer.salesforce.com/page/Security/Chimera
Раньше были вроде другие тулы.
Может у кого будут более свежие данные.


[quote="vbay"]Как я понимаю чтобы выложить приложение, нужно как минимум ежа против шерсти родить?[/quote]
Ну как сказать. Это смотря с какой стороны посмотреть. Многие прошедшие эту тему скажут что там раз плюнуть.