Добро пожаловать в мой блог! Изначально он не задумывался как блог CRM разработчика, но жизнь сама внесла нужные коррективы. Тут я публикою все свои наблюдения относительно обозначенных в заголовке систем. Если Вы найдете в нем что-то интересное для Вас, как для заказчика, то буду рад сотрудничать с Вами! В моей компетенции 100% задач по MS CRM 3.0/4.0/2011:
MVP 2010, 2011
- Консалтинг
- Проектирование
- Разработка
- Обучение
MVP 2010, 2011
Смена языка в Процессах CRM 2011
Запись от Артем Enot Грунин размещена 02.12.2011 в 19:51
Обновил(-а) Артем Enot Грунин 02.12.2011 в 23:30
Обновил(-а) Артем Enot Грунин 02.12.2011 в 23:30
Одна из проблем с которой вы можете столкнуться в мультиязычных инсталляциях CRM - это привязка к languagecode различных системных объектов. Если перевести метки трансляции относительно просто, то, например, отчеты, процессы и диалоги могут оказаться настоящей проблемой! Дело в том, что настраивать систему, например, создавать и импортировать Решения можно только в базовом языке. Это приводит к тому, что созданный в таком виде отчет или диалог, может не появиться в решении после смены языка интерфейса!
В случае с отчетом дела обстоят относительно просто - его языковую привязку можно сменить через интерфейс системы, или отменить вовсе. С диалогами и процессами дела обстоят немного хуже. У этих объектов поле languagecode не вынесено на форму. Простым решением кажется выгрузить Решение как неуправляемое и сменить языковую привязку процесса.
Никогда так не делайте!
Уже загруженные в систему процессы, которые имеют идентификатор и инстанции застревают в ней навечно! Скорее всего данное поведение связано с тем, что процессы изначально версионны. Каждая публикация создает отдельную ветку эволюции процесса, при этом уже созданные инстанции продолжают жить своей жизнью. Смена языковой привязки не была учтена разработчиками, так что на эволюции всего процесса не скажется никак. Он уже имеет идентификатор в системе и этот идентификатор связан с первоначальной привязкой к languagecode.
Для того, чтобы все же не переделывать сложный процесс с нуля, создайте новый пустой процесс на нужном вам языке, после чего смените язык на базовый и добавьте его в решение без публикации!
Теперь импортируйте решение, распакуйте его и откройте в XML редакторе файл решения. Найдите в нем узел нужного вам процесса и посмотрите как называется соответсвующий ему файл ресурса. Там же найдите как называется файл "кривого" процесса, который был создан в неправильном языке.
Далее откройте эти XAML файлы в XML редакторе (для того, чтобы сделать это в Visual Studio придется сменить у этих файлов расширение, иначе студия будет пытаться открыть их в редакторе процессов). Теперь остается только скопировать разметку процесса из одного файла в другой и заменить все вхождения идентификатора "неправильного" процесса, идентификатором "правильного". Если вы не публиковали второй процесс, его идентификатор должен быть представлен нулями.
Теперь запакуйте и импортируйте измененное решение обратно в систему. Процессы должны стать доступны на обоих языках.
В свое время мне пришлось проделать подобную операцию раз двадцать, пока не нашелся правильный рецепт. Удаление процесса, исправление его идентификатора на новый и прочие манипуляции не помогали. Кажется это работает с процессами типа Рабочего процесса, но отчего-то не получается с Диалогами.
Еще один путь для манипуляции с языковыми настройками - опубликовать процесс как шаблон и на его основе создать новый с изначально правильным языком.
Надеюсь какой-то из этих советов позволит вам сэкономить те нервы, которые потерял я.
В случае с отчетом дела обстоят относительно просто - его языковую привязку можно сменить через интерфейс системы, или отменить вовсе. С диалогами и процессами дела обстоят немного хуже. У этих объектов поле languagecode не вынесено на форму. Простым решением кажется выгрузить Решение как неуправляемое и сменить языковую привязку процесса.
Никогда так не делайте!
Уже загруженные в систему процессы, которые имеют идентификатор и инстанции застревают в ней навечно! Скорее всего данное поведение связано с тем, что процессы изначально версионны. Каждая публикация создает отдельную ветку эволюции процесса, при этом уже созданные инстанции продолжают жить своей жизнью. Смена языковой привязки не была учтена разработчиками, так что на эволюции всего процесса не скажется никак. Он уже имеет идентификатор в системе и этот идентификатор связан с первоначальной привязкой к languagecode.
Для того, чтобы все же не переделывать сложный процесс с нуля, создайте новый пустой процесс на нужном вам языке, после чего смените язык на базовый и добавьте его в решение без публикации!
Теперь импортируйте решение, распакуйте его и откройте в XML редакторе файл решения. Найдите в нем узел нужного вам процесса и посмотрите как называется соответсвующий ему файл ресурса. Там же найдите как называется файл "кривого" процесса, который был создан в неправильном языке.
Далее откройте эти XAML файлы в XML редакторе (для того, чтобы сделать это в Visual Studio придется сменить у этих файлов расширение, иначе студия будет пытаться открыть их в редакторе процессов). Теперь остается только скопировать разметку процесса из одного файла в другой и заменить все вхождения идентификатора "неправильного" процесса, идентификатором "правильного". Если вы не публиковали второй процесс, его идентификатор должен быть представлен нулями.
Теперь запакуйте и импортируйте измененное решение обратно в систему. Процессы должны стать доступны на обоих языках.
В свое время мне пришлось проделать подобную операцию раз двадцать, пока не нашелся правильный рецепт. Удаление процесса, исправление его идентификатора на новый и прочие манипуляции не помогали. Кажется это работает с процессами типа Рабочего процесса, но отчего-то не получается с Диалогами.
Еще один путь для манипуляции с языковыми настройками - опубликовать процесс как шаблон и на его основе создать новый с изначально правильным языком.
Надеюсь какой-то из этих советов позволит вам сэкономить те нервы, которые потерял я.
Всего комментариев 0
