Sandboxy v Salesforce jsou skvělá věc, umožní vám vyvinout a otestovat funkcionalitu a pak ji hezky přenést do ostré verze. Jenom není všechno zlato co se třpytí.
Sandboxů je několik verzí, od těch vývojářských, které jsou zadarmo k dispozici v každé edici, až po ty, do kterých můžete snadno přetáhnout všechna data a platí se za ně extra.
A tady leží jádro pudla. Pokud chcete něco otestovat, tak k tomu dost pravděpodobně budete potřebovat data. Ideálně ta, která máte v ostré databázi, abyste si mohli otestovat, že to na nich bude také fungovat správně.
To je okamžik, kdy si začnete rvát vlasy z hlavy a nadávat, protože dostat tam ta data není nijak snadné. Asi proto se za ty sandboxy, kam je možné data snadno dostat, platí extra.
Jak na to prostředky SF?
Salesforce má export a import, můžete využít Data Loader nebo workbench.
Ve všech případech si narazíte zuby na těch samých místech. ID záznamů, pod kterými jsou spárované navzájem, jsou unikátní pro každou instanci. Takže pokud máte záznamy provázané mezi sebou, musíte si vytvořit další pole, které prohlásíte za ID externího systému a budete párovat proti němu. Což není takový problém.
Problém začne být v okamžiku, kdy máte například firmy v hierarchii. Dost pravděpodobně se ta podřízená firma bude chtít importovat dřív než ta nadřízená a celé to selže. Takže budete muset importovat dvoukolově nebo mít štěstí.
Dalším problémem jsou neaktivní uživatelé, kteří jsou stále vlastníky záznamů. V běžném provozu to až tolik nevadí, při importu se tyto záznamy nenačtou.
Typy záznamů (record types) jsou další položkou, která je odkazována pomocí ID a to se v sandboxu bude lišit. Takže export, který jste dostali z ostrého systému, budete muset projet a příslušná ID ručně nahradit.
A tak to jde dál a dál, není to žádná věda, jenom spousta práce. Jako ostatně kterýkoliv import.
Online řešení?
Možná proto, že je to tolik práce, tak vznikla online řešení. Potkal jsem jich pár, jediné vyzkoušel. Většina má verzi zadarmo, která je omezena na počet nebo objem dat, ale pro přenos ukázkových dat do sandboxu i to může stačit.
Syncfrog, sfApex, SFXOrgData, využití ETL, WingmanData.
Zkoušel jsem ten poslední a když se mi podařilo na stránkách najít ten správný odkaz, tak už to šlo ráz na ráz. Pravděpodobně díky nějaké chybě se mi totiž pořád nabízel pouze odkaz na zálohování místo na přenos dat.
Šlo to ráz na ráz, byť to všechny problémy neodstranilo. Zadat přihlašovací údaje (hned po přenosu můžete přegenerovat Security Token a tak zabránit, aby údaje někdo zneužil), vybrat objekty, určit v jakém pořadí se mají importovat (bohužel to nezabrání chybě při podřízenosti záznamů stejného typu), vybrat jaká pole se mají importovat (a nezapomenout na odebrání odkazů na záznamy, které neimportujete), přidat filtrovací pravidla a importovat. Prý se má počítat s 5 000 záznamy každé tři minuty. Mě to vycházelo spíš tak na třicet minut, ale to nevadí, hezky si to jede na pozadí a naimportovalo to toho značně víc než ty moje pokusy pomocí workbench.
Poučení
Pokud se tomu můžete vyhnout, tak se tomu vyhněte. Není to mentálně náročné cvičení, je to jenom náročné časově, nutností přepisovat hodnoty a trápit se s nekonzistencí dat, která normálně až tolik nevadí. Ať si ti uživatelé vytvoří pokusné záznamy ručně. Nebo ať vedení kouká zaplatit ty lepší sandboxy.
Jo, nedávno jsem přenášel nejen data ale i strukturu z jedný produkční instance do druhý produkční a myslel jsem, že u toho potratím… Dobrovolně už nikdy 🙂
A narazil jsem na pár výjimek, který prostě přenést nedokážu. Tak třeba tabulku OpportunityTeamMember nelze naimportovat, protože to DataLoader vůbec nenabízí. Nebo aktivity (Tasks) – lze vyexportovat pouze tasky za poslední rok, protože ty starší jsou automaticky archivovaný a nelze se k nim přes API dostat. Holt smolík 🙁 Zajímavý je, že v kompletní záloze ze SF jsou i ty starší, jenže v tom CSV zase pro změnu chybí IDčka objektů, ke kterým se tasky vážou. Takže je to úplně k ničemu.
Občas si v poslední době říkám, že zlatej Microsoft 🙂
A ještě teda doplním moje zkušenosti s migrací struktury (z produkční do produkční instance). Na výběr je buď nepoužitelnej Force.com Migration Tool nebo nepoužitelnej Force plugin do Eclipse. Nakonec jsem většinu potřebného přenesl přes balíčky: Setup – Create – Packages. Nejde tak přenést všechno a dalo to hodně a hodně zkoušení, ale většina se nakonec podařila. Jen je potřeba znát fintu, jak hotový a publikovaný balíček nainstalovat do cílové instance. Ve vytvořeném odkazu je nutné změnit název domény (serveru) https://login.salesforce.com/packaging/installPackage.apexp?p0=04t160xxxx třeba na https://EU2.salesforce.com a to přesně podle toho, jaký název je vidět po přihlášení do cílové instance. A před instalací pár minut počkat, než SF balíček po publikaci rozdistribuuje na ostatní servery, jinak to hází chyby. Když o tom tak přemejšlím, tak bych to mohl podrobnějc popsat v článku.
Co nešlo přes balíčky, jsem pak synchronizoval pomocí https://gearset.com/, což je online utilitka od známé firmy RedGate. Zatím je to beta (zdarma) a přenos komplet celé struktury nezvládne, ale na drobnosti to stačilo a dá se čekat, že z toho bude slušný produkt.
Pár zbývajících věcí, které se nepodařilo přenést pomocí jednoho ani druhého kroku, už jsem doklikal ručně.
A pak nastala ta pakárna s importem dat. Zmíněné v článku „Takže pokud máte záznamy provázané mezi sebou, musíte si vytvořit další pole, které prohlásíte za ID externího systému a budete párovat proti němu. “ bohužel nejde použít při importu tabulek (objektů), které nelze v SF modifikovat a vytvořit si tam pole pro externí ID. Nezbylo než si předem ze SF vyexportovat již naimportované tabulky, všechno nalít do nějakého nástroje (v mém případě do MS SQL), tam si udělat potřebné JOINy a výsledek naimportovat zpět do SF. A tak postupovat s každou další složitější tabulkou. Opravdu blbá práce… Nechápu, proč už dávno v SF neudělali nějaký lepší nástroj nebo v DataLoaderu nepovolí „identity insert“, tj. vkládání IDček bez jejich nového generování. Taková drobnost a kolik by ušetřila práce!