Dynamics CRM: Usuwanie i ponowne dodawanie relacji o tej samej nazwie

Dynamics CRM to aplikacja, której dostosowywanie i programowanie wymusza na osobach odpowiedzialnych za ww. czynności ciągłą czujność. O tym, czym może skończyć się brak czujności – poniżej.

Wyobraźmy sobie relację między 2 encjami, o jakże odkrywczych nazwach: „new_testentitya” (Test Entity A) i „new_testentityb” (Test Entity B). Każda relacja w systemie CRM posiada własną nazwę (w omawianym przypadku będzie to domyślnie: „new_new_testentitya_new_testentityb”) oraz powiązana jest z polem typu lookup, którego nazwę znajdziecie na poniższym screenie.

a

 

Wyobraźmy sobie teraz, że importujemy tą relację do innego środowiska CRM za pomocą standardowego mechanizmu eksportu/importu dostosowań. Wszystko przebiega prawidłowo.

Wyobraźmy sobie następnie, że nie podoba nam się nazwa pola lookup, które zostało utworzone razem z relacją (w naszym przypadku: „new_testentityaid”). Usuwamy omawianą relację w środowisku źródłowym, a następnie dodajemy ją ponownie (nie zmieniając domyślnej nazwy) z nową nazwą powiązanego atrybutu (patrz. screen poniżej).

b

Importujemy ponownie relację na drugie środowisko, celem wprowadzenia zaimplementowanych zmian. Efekt jest niestety żaden. Pole „new_testentityaid” w środowisku testowym nie zostaje zmienione na „new_parententityid”. Dlaczego? Bo tak. CRM – pomimo ponownego utworzenia relacji i zmianą jej GUIDa w bazie SQL, ponieważ ma ona (relacja) taką samą nazwę jak relacja, która istnieje już w środowisku docelowym – ignoruje nowo-utworzony atrybut w czasie importu dostosowań (zamiast rzygnąć wyjątkiem, co byłoby w tym przypadku wskazane).

Wyobraźmy sobie teraz, że nieświadomi opisanego powyżej faktu, próbujemy odwołać się do atrybutu „new_parententityid” w kodzie .NET lub JavaScript. Efekt każdy może sobie wyobrazić: błędy, wyjątki, zgrzytanie zębów testerów oraz rozpacz biznesu :O.

Obywatelu-„dostosowywaczu”, bądź czujny!

 

Total Views: 1557 ,