Data migration - это отдельная большая тема с множеством нюансов, но сейчас предлагаю рассмотреть простейшую ситуацию: перенос данных из одного орга в другой орг с аналогичным набором приложений.
То есть данные переносятся в объект с той же самой структурой.
Проблема в правильном сведении внешних ключей, и восстановлении прежней связанности записей. Точнее говоря, проблема в том что в новых объектам на каждую запись выдадут новый GUID, и их нужно заменять и в полях записей других объектов (или этого же) ,содержаших эти GUIDы в качестве внешних ключей.
Не уверен, что я делаю правильно, но алгоритм такой:
(1) составляем схему объектов, связей и вычисляем очередность заполнения новых объектов датой, при этом создает в новом объекте временное поле, в которое пишем старые GUIDы.
(2) заливаем датой первый объект и экспортируем два поля (новые GUID и старые GUID).
(3) в подготавливаемом csv файле с полях с внешними ключами в виде GUID с помощью функции LOOKUP excelа заменяем старые на новые GUID.
(4) ипортируем записи с уже правильными GUID.
Но я видел в workbook как в качесте внешнего ключа для сведения записей при импорте используется не GUID, а какое-то поле с уникальным значением и помеченное как external ID. Это намного проще, так как это поле при записи сохраняется и ничего шаманить не нужно.
Но я не могу экспортировать в Data Loader поле из связанное объекта, которое могло быть ориентиром.
Например, я хочу получить сл поле:
ИпортируемыйОбъект.СвязанныейОбъект.ПоляКотороеМнеНужноВКачествеКлюча.
Data Loader дает доступ только к собственным полям экспортируемого объекта...
Миграция данных - это отдельная большая тема. Честно признаюсь никогда этим не занимался.
У нас на фирме для этого есть специальный человек, который занимается только миграциями данных, что говорит о масштабе этой области.
Den, ты все правильно написал - миграция данных это многоступенчатый процесс.И в принципе все происходит по твоему алгоритму.
Вот статья на эту тему:
http://wiki.developerforce.com/page/Data_Loader_and_relationships
Отталкиваясь от этого алгоритма можно придумать свой план по миграции.
Точной рецепта не существует, все зависит от самих данных.
Все правильно - экспортировать можно только один объект за один проход Data Loader. В статье выше подробно описано как правильно использовать поле ExternalID и чем его заполнять.
PS. на будущее. GUID надо называть ID - это стандартное основное поле КАЖДОГО объекта в SF. Не все поймут что ты подразумеваешь под GUID.
Спасибо Дмитрий!
Вот в этой статье я и нашел ответ на вопрос, как упростить мою схему. В шаге 4 в статье и написано самое главное. Старый ID используй как External ID, по которому и будут сопоставляться связанные записи.
Я называл SF ID Globally Unique Identifier (GUIDами), чтобы подчеркнуть, что в SF первичные ключи уникальны в пределах системы (и мира), поэтому при мигрировании данных сохранить первичный ключ никак не получится, системы выпишет новый, а это и требует поиска другого поля по которому будет идти сопоставление.
Есть еще другая большая тема - это миграция приложений из орга в орг с помощью Ant and migration tool.
Но я еще не изучил этот вопрос достаточно хорошо, чтобы задавать грамотные вопросы.
Просто коротко опишу проблему с которой столкнулись: похоже на то, что при переносе компонетов приложения (объектов, классов, тригеров и пр.) также необходимо соблюдать какую то последвательность\алгоритм, иначе - не получается. Пока это все, что знаю об этом.
GUID хорошее понятие. Сам им пользовался когда программировал на другой платформе. Вместо auto increment значения предпочитал использовать GUID, которые в идеальном случае представляли собой уникальное в природе значение. Приятно было ощущать что запись, которую ты создал является уникальной и ее можно идентифицировать независимо от того где она находится. Как-то читал показательную историю одно программиста, который помог своей фирме не влететь на крупные бабки - в биллинговой системе кто-то умудрился смешать тестовые данные по оплате с реальными. Помогли только GUID 
Что касается Salesforce, то ID являются уникальными только в пределах одного орга (твоего окружения) и содержат в себе кроме уникального значения для записи еще и идентификатор объекта. Но уже на уровне двух и более оргов уникальность не гарантируется, поэтому ID заново генерируются при переносе данных.
По поводу миграции кода с помошью Migration tool - тут все НАМНОГО проще чем при миграции данных. Вот эта моя статья позволит смело приступать к мигрированию кода, а если еще немного покопаться в документации, то будешь чувствовать себя как рыба в воде
Тот же код можно перенести с помощью Force.com IDE (Force.com->Deploy to Server), но это всего лишь обертка над тем же Migration tool.
Как ты правильно отметил, при миграции кода тоже есть своя последовательность (шаги) но она диктуется только зависимостями в коде. Тут ничего сложного нет, это как размотать клубок ниток - найти начало, элемент который ни от кого не зависит.
И то, поверь моему опыту, такие случаи бывают крайне редко и встречаются на "больших" проектах с огромным количеством зависимостей. Тут главное разобраться со всеми ошибками и тогда код перенесется как одно целое.
Продолжу тему переноса Приложения.
Ситуация: сендбокс с десятком приложений, созданными разными людьми до меня, с которыми уже нет связи.
Задача: перенести Приложение с тремя десятками кастомных объектов в другой Орг, причем я вижу, что некоторые из этих объектов используются и в других приложениях исходящего сендбокса.
Что я хочу: аккуратно перенести Приложение, используя Экклипс.
Вопросы:
(1) Можно ли и как с помощью Экклипса выгрузить из Орга компоненты только одного нужного мне Приложения? Дело в том, что я еще не разобрал какие страницы, классы, тригеры, документы и ресурсы относятся именно к этому Приложению. Поэтому было бы здорово, если бы Экслипс выдернул из кучи всего, что есть в сендбоксе только то, что является частью этого Приложением.
(2) Как затем загрузить Приложение из Экклипс на новый орг и нет ли в этом процессе подводных камней?
(3) Если придется в ручную выбирать классы-триггеры-ресурсы-страницы, есть ли быстрый путь определить к какому объекту-приложению относится тот или иной элемент? Предполагается, что в АРЕХ классах и т.д. сендбокса могут быть элементы самых разных приложений.
(4) Какие еще элементы Приложения нужно переносить, кроме очевидных компонентов, которые я указал выше. Например, профили, роли, типы Записей (они часть кастомного объекта?), Workflow and rules, очереди?
Заранее Спасибо
Очень интересный случай.
Сразу скажу что какого-нибудь автоматического способа разделить кучу куда на отдельные приложения нет. Ты сам пойми что как для SF так и для тебя это одна большая куча кода и разбираться придется в ней исходя только из логики.
Сразу советую тебе подружиться с Migration Tools (Ant). Там ничего сложного нет, но он лучше подойдет для этих целей чем Eclipse.
И вот почему:
Я так понял что приложения на твоем dev орге существуют в виде отдельных Apps (Setup->Create->Apps). Если так, то начни с них.
Выгрузи с помощью Migration Tools, только этот App (его определение). Попытайся залить на новый орг. Естественно ты получишь ошибку что тебе не хватает Tabs от которых зависит этот App. Идешь в Migration Tools и прописываешь все Tabs. Опять выгружаешь все с старого орга и пытаешься залить на новый. Опять будут ошибки о том что для Tabs не хватает Visualforce Pages и Custom Objects. Прописываешь их ... И так далее по кругу пока ты не вытянешь все зависимости.
Так ты получишь основную часть приложения, но не полную. Триггеры на объектах так не вытянешь, они не попадают в зависимости - придется смотреть каждый объект и собирать триггеры в ручную. Возможно что-то еще не подтянется, но это будут уже мелочи, которые ты выявишь в результате тестирования вынесенного приложения на новый орг.
Пробуй :)
Ну что ж, придется разбираться с переносом Приложения "вручную". Спасибо за ответ.
вот продолжение темы переноса описанного выше запутанного App между разными Оргами.
Пытался перенести все "одним махом", но не получилось.
Вначале создал на Орг package в который включил требуемый App.
Попытался выгрузить этот package в SF как unmanaged package. Не вышло - нет тестовото покрытия классов и триггеров.
Но тем не менее этот package пригодился позже: с помощью Ant я выгрузил себе на комп этот package, содержащий требуемый Арр.
Но при попытке загрузки в новый Орг пошли бесчисленные ошибки всех типов (на новом Орг в стандартных объектах нет требуемых кастомных полей, нет групп, нет...) как только я разрешил, как казалось, все ошибки, при следущей попытке загрузки три десятка новых...
В общем, от идеи загрузки "одним махом" приходится отказаться.
Завтра буду пытаться перетянуть по одному объекту(если он не связан) или по несколько связанных объектов.
В связи с этим все тот же вопрос: можно ли для этого как-то приспособить Эклипс, он в отличие от Ant дает графический интерфейс, что может ускорить работу...
спасибо
Это все тоже можно перенести с помощью Ant. Смотри в документации как описать эти элементы в package.xml
Эклипс никак не ускорит работу, а только замедлит ее. Пока тебе кажется тяжело, потому что ты разбираешься с Ant. Лучше сейчас потратить время, чтобы потом было легче. Проблема в Eclipse при миграции кода в том, что иногда в исходный код надо внести изменения чтобы сохранить на новом орге и эти изменения Eclipse по-умолчанию сохранит на старый орг, что собственно не нужно. С помощью Ant ты вытянешь исходный код и можешь делать с ним что угодно, не боясь сломать что-то на родном орге.
Веду подготовку к последовательному переносу приложения.
Закрались смутные сомнения:
(1) А через Ант возможно ли перенести код без тестового покрытия?
(2) нашел два кастомных объекта с кольцевой зависимостью: один берет в лук-ап поле запись второго объекта, а второй объект берет в свое лук-ап поле запись из первого объекта. Как бы не было проблем. Или придется в новом орге создавать вручную второй объект (с одним полем), затем сажать первый объект, и до-переносить нехватающие поля во второй объект. Но посмотрим, может ларчик и проще открывается...
(3) и проблема: как узнать какие объекты включает в себя Арр, если нужно вывести его из очень-очень смешанного сэндбокса? я сделал пакедж данного Арр в орге, затем выгрузил этот пакедж Антом и посмотрел в содержимое <name>CustomObject</name> package.xml. Думаете там есть все требуемые объекты? а вот и нет, еще 13 связанных с включенными в package кастомных объектов (в большинстве это child объекты по M-D связи) я нашел только перебором всех объектов в Схем билдере...
(4) Можно ли перенести только одно кастомное поле в стандарном объекте? можно перенести и весь стандартный объект, но не уверен, что все его кастомные поля потребуются в переносимом приложении.
(5) определил что все объекты в приложении образуют несколько не связанных друг с другом групп. И возникла идея перенести сначала только одну группу объектов (вместе с требуемыми полями стандартных объектов). Но почитал ответы вышел и понял, что "под крышей" Арр не удастся перенести только несколько объектов, даже если все их зависимости покрыты. App (предположительно) будет требовать все или ничего. Тогда не буду переносить App вообще, после переноса всех компонентов создам на месте еще раз этот App c тем же названием. Но это все планы. Как все будет на самом деле - увидим позже.
В любом случае это будет ценных опыт. А это самое главное.
Можно, если это другой dev или sandbox. Покрытие требуется ОБЯЗАТЕЛЬНО только если заливаешь на prod.
Если оба объекта заливаются вместе, то никаких проблем не должно быть (должно залиться). Вот по отдельности не получится.
Все правильно. Вот такие итерации (выгрузка->проверка чего не хватает->добавление в package.xml->выгрузка) надо повторять много раз, пока все зависимости не закончатся (пока всю цепочку не раскрутишь). Да это нудное занятие, но в твоем необычном случае именно так и надо делать.
Да можно. Надо вытянуть антом этот стандартный объект (выльется все что есть на орге), после чего отредактировать .xml описание этого объекта (удалить все что не нужно). Но только не забудь, что при следующем вытягивании этого объекта твои изменения затрутся исходными данными (необходимо принять меры, чтобы повторно не редактировать описание).
Можно создать App отдельно, тоже как вариант.
В любом случае, я советую сначала понять что каждое приложение делает и как работает и уже потом производить их разделение. Тогда и package.xml составить будет вообще не проблема. Пока простое расчленение по зависимостям не самый лучший вариант.
Как один из вариантов худшего развития событий - у приложений могут быть общие части и тогда ты точно застрянешь в этих зависимостях.
BUILD SUCCESSFUL
Невероятно, но после многих попыток, размышлений, корректировок я загрузил этот клубок связей и зависимостей в мой Дев Эккаунт.
Вижу все объекты, вижу этот Апп в Setup->Apps, вижу этот Апп в настойках Apps меню (вверх-вниз), но не вижу его в самом Apps меню (в вверхнем правом углу экрана), т.е. доступа к функционалу нет. Еще не разобрал в чем проблема, но подумаю об этом завтра, на сегодня достаточно экспериментов.
Если у вас есть идеи в чем там дело - подскажите, буду премного благодарен.
Все просто. Проверь настройку прав доступа для профиля (у тебя наверное System Administrator). Все что ты залил будет недоступно по умолчанию.
Спасибо, Дмитрий.
Можно подвести некоторые итоги проделанной работе по переносу приложения. Не могу сказать, что мои выводы верные, но пока есть, что есть.
Итак, если хотите перенести комплексное приложение из смешанного сендбока - соберите этот Арр в package и выгрузите его!
Но важно: как я понял, в package собираются только те объекты и их компоненты, у которых есть видимый Таб в данном Арр.
Значит вначале внимательно изучите структуру Арр в СхемБилдере, затем сделайте Таб для всех участвующих объектов и заведите их в Арр. После этого package соберется практически полным. Также убедитесь, что в Табах данного Арр случайно не затесались посторонние объекты из других частей Орга.
И последнее: перенос кастомных полей стандарных объектов, требуемых в Арр. Пока у меня нет ясного ответа, сделает ли это package, поэтому я делал это отдельно.
Также package не перенес требуемые (где-то) Public Groups. Плюс в package ХМЛ файле были перечислены компоненты NamedFilter, но их не было в папках.
Спасибо за помощь
В принципе все правильно написал.
Только табы создавать для кастомных объектов не нужно. В App уже будет необходимый набор табов связанных с Visualforce страницами. Страницы соответственно с контроллерами. Контроллеры будут использовать объекты которые, собственно и относятся к данному приложению. Важно потом не забыть про triggers для объектов. На них обычно никто не ссылается и поэтому их вытянуть через зависимости не получится.
Кастомные поля стандартных объектов. Если не хочется заморачиваться, то проще вручную. Но опять же лучше один раз поеб... чтобы потом проще было :)
В package собралось несколько ApexTriggers, очень надеюсь, что это все что нужно.
Не могу понять, почему потребовались несколько Groups в новом Орге (это единственное, что я делал вручную в новом Орге, а не переносил), и почему они не собрались в package, если такое возможно.
Получил опыт загрузки Documents and Attachment.
Во-первых: они не одно и тоже, как может показаться, это разные объекты.
Во-вторых все прекрасно делается через DataLoader.
Хотел, сначала загружить Attachmentы, затем программно привязать их к соответвующим записям.
Но в поле ParentID нужно что-то давать. Не стал пытаться привязывать сотню атачментов к одной тестовой записей, а потом програмно перелинковать, так как не знаю лимиты (по размерам? по кол-ву?) атачей, которые можно привязать к одной записи.
все сделал в CSV и загрузил.
Обнаружил, что в SF нет стандарных средств для визуализации того, что лежит в объекте Attachment. Получается, что только кверить. Или есть каие-то способы посмотреть Attachment?
Если тебе надо более красивая работа с загруженными документами, то посмотри в сторону CRM Content
Сколько там всего есть в SF! только учи и учи
начал с этим разбираться вот здесь
Setup->Administration Setup->Data Management->Storage Usage and than Current File Storage Usage->Attachments
и вижу, что там указан общий размер уже загруженных аттачей в Мб (колонка Storage) и процент от использования (колонка Percent), но сам лимит не указан...
Указан только общий лимит на хранение файлов File Storage колонка Limit.
Можно конечно посчитать размер лимита от загруженного размера и сколько это получилось процентов лимита, но как-то недобно...
Прикрепил пример Storage Usage со своего тестового орга, чтобы не быть голословным (ниже).
Что-то совсем не понял что ты хочешь там высчитывать.
Attachments хранятся в File Storage который составляет 20Мб (в моем примере) и они занимают 54 KB. Т.е. места еще хватает.
Еще не разобрался толком с типами Оргов (Прод, сендбокс), и вопрос такой: те лимиты, которые я вижу в сэндбоксе какого-то действующего Орга - это лимиты Прода+Сендбокс, или это только лимита данного сэндбокса, а у Прода они свои. Не могу проверить это, нет доступа к Проду. Но кажется это лимиты только сендбокса: слишком мало использовано....
В общих чертах есть три категии оргов:
- девелоперский орг
- продакшен
- сандбокс
с дев оргом понятно - это орг который ты можешь зарегать бесплатно с очень ограниченными лимитами.
продакшен - это орг который покупается за деньги. Его лимиты зависят от edition (то что я писал про salesforce цены).
сандбокс - это слепок с прода (его копия). Есть два типа сандбокс - configuration only и full copy. Сандбоксы имеют лимиты такие же как и прод.
OK, спасибо!
А сколько сендбоксов можно сделать? Они за них тоже деньги берут?
Как происходит размещение апекс кода в Прод: просто перетаскиваешь через Эклипс? как Прод узнает, что этот был оттестирован или нет? (еще не было опыта работы непосредственно с Продом, поэтому вот такие вопросы...)
Сандбоксов может быть много и, да, они платные. Точнее не скажу потому что не занимался созданием сандбоксов.
Размещение кода на проде выполняется с помощью деплоя. Во время деплоя проверяется код на ошибки и если все нормально, то запускаются все тесты. Если тесты прошли и суммарное покрытие кода на проде более 75% то код сохраняется, иначе получаешь ошибку и все изменения откатываются (т.е. изменения не производятся)
Очень надежная система Сломать что-то будет тяжело!
Кто-нибудь заглядывал в раздел Deploy в Setup. Этого раздела вроде нет в простых Девелопер эккаунтах, он есть только в сендбоксах и работающих оргах.
В Deploy размещены связи между оргами (сендбокасми) и возможность отправки пакетов с метаданными между ними.
Salesforce никогда не перестанет меня удивлять...
!!! OOOOO Deploy это крутая штука для миграции кода между sandbox <-> sandbox и sandbox -> production.
Постоянно ей пользуюсь при работе.
Данные переносятся между оргами так называемыми changeSet. Они очень похожи на стандартные пакеты в Salesforce.
Очень сильно облегчает жизнь! А многие заказчики требуют использовать только changeSet для переноса кода и настроект прав доступа.
Из плюсов - удобное подтягиваение зависимостей в changeSet (очень помогает чего нибудь не забыть) и возможность провести пробный деплой на проде без реального изменения данных (Verify). Последнее ОЧЕНЬ классно помогает подготовиться к деплою заранее, чтобы в назначенный день не бегать с пеной на губах из-за повалившихся тестов. :)
Действительно, очень полезные функции.
после этого остается только спросить, а зачем нужен Эклипс? какие уникальные функции остаются у него? кроме сохранения метаданных на локальный носитель.
ну в общем да. Если простыми словами, то в changeSet зависимости подтягиваются в ручном режиме по кнопке Show Dependencies в отличии от пакетов.
Добрый день!
Хочу поднять тему этого топика и спросить у людей, имеющих опыт переноса данных - какими тулзами пользовались, их плюсы и минусы, возможные подводные камни..
Стоит задача переноса данных с прода на девелоперский сэндбокс, структура данных - 5 связаных через мастер-дитэйлы и лукапы объектов, среди них несколько кастомных, а также аккаунт и опотьюнити.
Поиск информации в интернете по этой теме позволил составить такой список решений:
До этого н еработал ни с чем из этого списка кроме даталодера, хотел бы спросить, кто чем пользовался и что может порекомендовать.
Стоит задача переноса данных с прода на девелоперский сэндбокс, структура данных - 5 связаных через мастер-дитэйлы и лукапы объектов, среди них несколько кастомных, а также аккаунт и опотьюнити.
Поиск информации в интернете по этой теме позволил составить такой список решений:
До этого н еработал ни с чем из этого списка кроме даталодера, хотел бы спросить, кто чем пользовался и что может порекомендовать.
Если объем записей не большой(меньше 50 тыс.), то порекомендую использовать workbench - не требует установки, умеет работать по внешним ключам. Если данных больше, то я бы пошел с Jitterbit, который еще даст некоторые другие плюшки, но это сугубо имхо, ибо многие предпочитают стандартный даталоудер.
Talend, SFXOrgData несколько для других целей, потому в данном тексте я бы их не рассматривал.
