Как известно за размер орга нужно платить, обсуждалось здесь:
Как решить проблему с нехваткой места в ХРАНИЛИЩЕ ДАННЫХ(1 GB)
и пришли ко мнению, что не такие уж и большие деньги они просят за расширение орга.
но как то на каком-то интервью меня спросили о том, как можно организовать храние Аттачей на внешнем сервере и работу в Орге с ними.
мне ничего в голову не пришло, как сказать что нужно сделать на внеш сервере ВЕБ сервис и пушить и пулить атачи с орга на сервер и обратно.
но потом подумал-подумал: а почему бы не поднять на внеш сервере одну страницу, на которую выводится лист атачей какой-то СФ записи (ID приходит в аргументах линка), где их можно подгружать, смотреть, удалять.
и эту страницу вставить ВФ пейдж и ВФ пейдж вставить на стандартный дитейл лейаут?
Ну в общем все правильно написал. Только нужно предусмотреть разделение доступа к файлам. Как это будет организовано через страницу, вебсервис, рест не принципиально. Главное чтобы было грамотно подумать заливку с возможностью докачки. Доступ через веб должен быть только с салесфорса + разделение доступа иначе все смогут смотреть все. Я например использую временные ключи для доступа к файлам, то есть урл файла на скачку всегда разный.
Куда проще и правильнее хранить на СФ ссылки на файлы на внешний сервер, никаких проблем с шарингами записей нет. а сам сервис это уже REST со своими potgetputdelete. незачем изобретать колесо как говорится. имхо
Вот тут ты не прав. Разделение доступа должно быть. Делал подобный сервис для медицинской конторы. Там один файлик был по 300 мега и так же там была кастомная регистрация. Так вот там без проверки прав никак.
Требование клиента сподвигают заниматься этим
клиенту всегда можно объяснить, что то и то лучше сделать так и так.
ибо на собственном примере(клиент просто не обращает внимание на советы) один очень интересный проект(срубил недавно американских денег много на развитие) превращается большую мусорную яму....
Я не говорю что все клиенты правы. Но в данном случае это правильно и не потребовало много усилий.
УПД: и ссылки на эти файлы всеже хранились на стороне СФ?
Ссылки хранились на СФ. Права разделялись по profileid и уникальному ключу который хранился в контакте
Я сам не делал, но слышал, что если использовать Amazone s3 то там при запросе ссылки на скачивание можно сперва послать спец запрос сервером и получить уникальную одноразовую ссылку для скачивания и отдать ее уже пользователю. Тогда получится реальная секюрность.
Пришла в голову мысль: а можно хранить файлы в облачном файлехранилище как Dropbox?
тогда в Орге у нас будет кастомный объет Аттачменты, который хранит все ключевые атрибуты файла. а одно из полей типа URL - это линк, ведущий на файл в Дропбоксе (линк содержит в аргументах все что нужно для авторизации).
и в рел листах записи выводить список кастомных аттачей и то поле-линк при клике на которое подгружается соответствующий документ.
для загрузки файла придется писать небольшую ВФ странитцу, которую вставлять на Дитейл лейут чуть ниже того Рел-листа.
Можно и дропбокс и любое внешнее файлохранилище, хоть Youtube.
Кстати по поводу сервисов от google (youtube, docs, calendar)
у меня есть одно наблюдение (когда-то давно экспериментировал, не знаю как сейчас дела обстоят)
Цель экперимента прикрутить google api к Salesforce. Но споткнулся об авторизацию.
Думаю сейчас все воскликнут - что тут сложного. Авторизация проходит через Auth2.0 т.е. в большентсве примеров авторизация происходит через браузер с помощью редиректа на google и предоставления доступа приложению, получением токена. Но проблема тут в том что если так авторизироваться, то 10 пользователей авторизируются на свои 10 разных аккаунтов и будут загружать документы именно в свой аккаунт. Т.е. если положит один пользователь документ таким образом, то второй не будет его видеть (иметь возможность редактировать) без допольнительных танцев с бубном.
В общем необходима была авторизация с помощью username+password напрямую из salesforce. И тут возникла проблема - есть сложный алгоритм подготовки данных для такой авторизации и на последнем этапе используется хитрая процедура шифрования RSA SHA-256 которой тупо нет в Salesforce. На этом мой эксперимент обломился.
Вот нашел описание по которому я делал - https://developers.google.com/accounts/docs/OAuth2ServiceAccount
Кстати у меня была идея написать внешний веб сервис, который бы мне шифровал и возвращал итоговый запрос, но не хватило терпения.
! Эксперимент проводился давно (даже смотрю документация по ссылке немного изменилась) так что мои выводу могли устареть. Если вы знаете способ как законектиться к google api без участия пользователя, буду очень признателен.
К чему я поднял вопрос про Dropbox. в руках в качестве новогоднего чтива книжка Jonathan Sapir "Saleasforce1 101" (о более ранее версии этой книги я уже писал в Общем разделе). Содержание - простое объясненеие для менеджеров что может Saleasforce без техн подробнеостей. иногда полезно и нам читать чтобы понимать общую картину платформы. ну так вот там есть картинка объясняющая далеким людям для чего нужен API - и в качестве примера интеграции приведен Dropbox. так что я подумал, что может этот вопрос уже решен...
зачем поднимать собсвтенный сервер, если можно хранить файлы в облачном сервисе? хотя вот этот вопрос - это уже отдельная тема для обсуждения.
