Eski Verileri Bozmadan Taşıyın

Eski verileri taşımak zordur.

Birçok kuruluş, eski ve karmaşık şirket içi iş CRM sistemlerine sahiptir. Bugün, birçok fayda sağlayan çok sayıda bulut SaaS alternatifi var; kullandığın kadar öde ve sadece kullandığın kadar öde. Bu nedenle yeni sistemlere geçmeye karar verirler.

Hiç kimse eski sistemdeki müşterilerle ilgili değerli verileri bırakıp boş yeni sistemle başlamak istemez, bu yüzden bu verileri taşımamız gerekiyor. Ne yazık ki, dağıtım çabasının yaklaşık yüzde 50'si veri taşıma etkinlikleri tarafından tüketildiğinden, veri taşıma kolay bir iş değildir. Gartner'a göre Salesforce, bulut CRM çözümlerinin lideridir. Bu nedenle, veri geçişi Salesforce dağıtımı için önemli bir konudur.

Peki, eski verilerin parlak yeni bir sisteme başarılı bir şekilde geçişini nasıl sağlayabiliriz ve tüm geçmişini koruyacağımızdan nasıl emin olabiliriz? Bu yazıda, başarılı veri geçişi için 10 ipucu sunuyorum. İlk beş ipucu, kullanılan teknolojiden bağımsız olarak herhangi bir veri geçişi için geçerlidir.

Genel Olarak Veri Taşıma

1. Göçü Ayrı Bir Proje Haline Getirin

Yazılım dağıtım kontrol listesinde, veri geçişi, hedef sistemler için önceden tanımlanmış eşlemeye sahip akıllı bir "tek tuşa bas" veri geçiş aracı tarafından işlenen bir "dışa ve içe aktarma" öğesi değildir.

Veri taşıma, ayrı bir proje, plan, yaklaşım, bütçe ve ekip gerektiren karmaşık bir faaliyettir. Projenin başlangıcında, "Ah, bu müşterilerin ziyaret raporlarını yüklemeyi unuttuk, bunu kim yapacak?" gibi sürprizlerin olmamasını sağlayacak şekilde varlık düzeyinde bir kapsam ve plan oluşturulmalıdır. son teslim tarihinden iki hafta önce.

Veri taşıma yaklaşımı, verileri tek seferde mi yükleyeceğimizi ( big bang olarak da bilinir) veya her hafta küçük gruplar halinde mi yükleyeceğimizi tanımlar.

Yine de bu kolay bir karar değil. Yaklaşım üzerinde anlaşmaya varılmalı ve tüm iş ve teknik paydaşlara iletilmelidir, böylece herkes yeni sistemde ne zaman ve hangi verilerin görüneceğini bilecektir. Bu sistem kesintileri için de geçerlidir.

2. Gerçekçi Tahmin Edin

Veri geçişinin karmaşıklığını hafife almayın. Projenin başlangıcında görünmeyen bu sürece birçok zaman alıcı görev eşlik eder.

Örneğin, eğitim amaçlı belirli veri kümelerini bir grup gerçekçi veriyle yüklemek, ancak hassas öğeler gizlenerek eğitim etkinliklerinin müşterilere e-posta bildirimleri oluşturmaması.

Tahmin için temel faktör, kaynak sistemden hedef sisteme aktarılacak alanların sayısıdır.

Alanı anlamak, kaynak alanı hedef alanla eşleştirmek, dönüşümleri yapılandırmak veya inşa etmek, testler yapmak, alan için veri kalitesini ölçmek vb. dahil olmak üzere her alan için projenin farklı aşamalarında bir miktar zamana ihtiyaç vardır.

Jitterbit, Informatica Bulut Veri Sihirbazı, Starfish ETL, Midas ve benzerleri gibi akıllı araçların kullanılması, özellikle oluşturma aşamasında bu süreyi azaltabilir.

Özellikle, herhangi bir geçiş projesindeki en önemli görev olan kaynak verileri anlamak, araçlarla otomatikleştirilemez, ancak analistlerin alan listesini tek tek gözden geçirmesi için zaman ayırmasını gerektirir.

Genel çabanın en basit tahmini, eski sistemden aktarılan her alan için bir adam-gündür.

İstisna, aynı kaynak ve hedef şemalar arasında daha fazla dönüşüm olmadan veri çoğaltmadır - bazen 1:1 geçiş olarak da bilinir - burada tahminimizi kopyalanacak tabloların sayısına dayandırabiliriz.

Ayrıntılı bir tahmin başlı başına bir sanattır.

3. Veri Kalitesini Kontrol Edin

Eski sistemlerden veri kalitesi sorunları bildirilmese bile kaynak verilerin kalitesini abartmayın.

Yeni sistemlerin, eski verilerle ihlal edilebilecek yeni kuralları vardır. İşte basit bir örnek. Yeni sistemde iletişim e-postası zorunlu olabilir, ancak 20 yıllık eski bir sistem farklı bir bakış açısına sahip olabilir.

Uzun süredir dokunulmayan ancak yeni sisteme aktarılırken aktif hale gelebilecek tarihi verilerde gizlenmiş mayınlar olabilir. Örneğin, artık mevcut olmayan Avrupa para birimlerini kullanan eski verilerin Euro'ya çevrilmesi gerekir, aksi takdirde yeni sisteme para birimlerinin eklenmesi gerekir.

Veri kalitesi çabayı önemli ölçüde etkiler ve basit kural şudur: Tarihte ne kadar ileri gidersek, o kadar büyük bir karmaşa keşfedeceğiz. Bu nedenle, yeni sisteme ne kadar tarih aktarmak istediğimize erken karar vermek hayati önem taşımaktadır.

4. İş İnsanlarını Etkileyin

Verileri gerçekten anlayan ve bu nedenle hangi verilerin atılabileceğine ve hangi verilerin saklanacağına karar verebilecek olan yalnızca iş adamlarıdır.

Haritalama alıştırması sırasında iş ekibinden birinin dahil edilmesi önemlidir ve gelecekteki geri izleme için, haritalama kararlarını ve bunların nedenlerini kaydetmek faydalıdır.

Bir resim bin kelimeden daha değerli olduğundan, yeni sisteme bir test grubu yükleyin ve iş ekibinin onunla oynamasına izin verin.

Veri geçiş eşlemesi iş ekibi tarafından gözden geçirilip onaylansa bile, veriler yeni sistemin kullanıcı arayüzünde göründüğünde sürprizler ortaya çıkabilir.

“Ah, şimdi anlıyorum, biraz değiştirmeliyiz” yaygın bir ifade haline geliyor.

Genellikle çok meşgul insanlar olan konu uzmanlarının katılımını sağlayamamak, yeni bir sistem devreye girdikten sonra sorunların en yaygın nedenidir.

5. Otomatik Geçiş Çözümünü Hedefleyin

Veri geçişi genellikle tek seferlik bir etkinlik olarak görülür ve geliştiriciler, bunları yalnızca bir kez yürütmeyi umarak manuel eylemlerle dolu çözümler bulma eğilimindedir. Ancak böyle bir yaklaşımdan kaçınmak için birçok neden var.

• Göç birden çok dalgaya bölünürse, aynı eylemleri birden çok kez tekrarlamamız gerekir.
• Tipik olarak, her dalga için en az üç taşıma çalıştırması vardır: veri taşımanın performansını ve işlevselliğini test etmek için bir kuru çalıştırma, tüm veri kümesini test etmek ve iş testleri gerçekleştirmek için tam bir veri doğrulama yükü ve tabii ki üretim yükü. Düşük veri kalitesi ile çalıştırma sayısı artar. Veri kalitesini iyileştirmek yinelemeli bir süreçtir, bu nedenle istenen başarı oranına ulaşmak için birkaç yinelemeye ihtiyacımız var.

Bu nedenle, taşıma doğası gereği tek seferlik bir etkinlik olsa bile, manuel işlemlere sahip olmak işlemlerinizi önemli ölçüde yavaşlatabilir.

Salesforce Veri Taşıma

Ardından, başarılı bir Salesforce geçişi için beş ipucu ele alacağız. Bu ipuçlarının büyük olasılıkla diğer bulut çözümleri için de geçerli olduğunu unutmayın.

6. Uzun Yükler için Hazırlanın

Performans, şirket içi bir çözümden bir bulut çözümüne geçerken en büyük ödünleşimlerden biridir - Salesforce hariç değildir.

Yerinde sistemler genellikle temel bir veritabanına doğrudan veri yüklenmesine izin verir ve iyi bir donanımla saatte milyonlarca kayda kolayca ulaşabiliriz.

Ama bulutta değil. Bulutta, çeşitli faktörlerle büyük ölçüde sınırlıyız.

• Ağ gecikmesi – Veriler internet üzerinden aktarılır.
• Salesforce uygulama katmanı – Veriler, Oracle veritabanlarına ulaşana kadar kalın bir API çoklu kiralama katmanından taşınır.
• Salesforce'ta özel kod – Birçoğu paralel veya toplu yüklemeleri devre dışı bırakan özel doğrulamalar, tetikleyiciler, iş akışları, yineleme algılama kuralları vb.

Sonuç olarak, yükleme performansı saatte binlerce hesap olabilir.

Alan, doğrulama ve tetikleyici sayısı gibi şeylere bağlı olarak daha az veya daha fazla olabilir. Ancak, doğrudan bir veritabanı yükünden birkaç derece daha yavaştır.

Salesforce'daki verilerin hacmine bağlı olan performans düşüşü de dikkate alınmalıdır.

Yabancı anahtarları, benzersiz alanları ve çoğaltma kurallarının değerlendirilmesi için kullanılan temel RDBMS'deki (Oracle) dizinlerden kaynaklanır. Temel formül, sıralama ve B-ağacı işlemlerinde O(logN) zaman karmaşıklığının neden olduğu her 10 derece için yaklaşık yüzde 50 yavaşlamadır.

Ayrıca Salesforce'un birçok kaynak kullanım limiti vardır.

Bunlardan biri, her partide maksimum 10.000 kayıt olmak üzere, 24 saatlik değişen pencerelerde 5.000 gruba ayarlanan Toplu API sınırıdır.

Yani teorik maksimum, 24 saatte yüklenen 50 milyon kayıttır.

Gerçek bir projede, örneğin özel tetikleyiciler kullanılırken sınırlı parti boyutu nedeniyle maksimum değer çok daha düşüktür.

Bunun veri taşıma yaklaşımı üzerinde güçlü bir etkisi vardır.

Orta ölçekli veri kümeleri için bile (100.000'den 1 milyona kadar hesap), büyük patlama yaklaşımı söz konusu değildir, bu nedenle verileri daha küçük geçiş dalgalarına bölmemiz gerekir.

Bu, elbette, tüm dağıtım sürecini etkiler ve önceki geçişler ve kullanıcılar tarafından girilen veriler tarafından zaten doldurulmuş bir sisteme veri artışları ekleyeceğimiz için, geçiş karmaşıklığını artırır.

Geçiş dönüşümlerinde ve doğrulamalarında bu mevcut verileri de dikkate almalıyız.

Ayrıca, uzun yükler, bir sistem kesintisi sırasında geçiş gerçekleştiremeyeceğimiz anlamına gelebilir.

Tüm kullanıcılar bir ülkede bulunuyorsa, gece boyunca sekiz saatlik bir kesintiden yararlanabiliriz.

Ancak Coca-Cola gibi dünyanın her yerinde faaliyet gösteren bir şirket için bu mümkün değil. Sistemde ABD, Japonya ve Avrupa olduğunda, tüm saat dilimlerini kapsarız, bu nedenle Cumartesi, kullanıcıları etkilemeyen tek kesinti seçeneğidir.

Ve bu yeterli olmayabilir, bu nedenle, kullanıcılar sistemle çalışırken çevrimiçiyken yüklemeliyiz.

7. Uygulama Geliştirmede Göç İhtiyaçlarına Saygı Duyun

Doğrulamalar ve tetikleyiciler gibi uygulama bileşenleri, veri taşıma etkinliklerini işleyebilmelidir. Sistemin çevrimiçi olması gerekiyorsa, geçiş yükü sırasında doğrulamaların kesin olarak devre dışı bırakılması bir seçenek değildir. Bunun yerine, bir veri taşıma kullanıcısı tarafından gerçekleştirilen değişiklikler için doğrulamalarda farklı bir mantık uygulamamız gerekiyor.

• Tarih alanları, geçmiş verilerin yüklenmesini devre dışı bırakacağından, gerçek sistem tarihiyle karşılaştırılmamalıdır. Örneğin, doğrulama, taşınan veriler için geçmiş bir hesap başlangıç ​​tarihi girilmesine izin vermelidir.
• Geçmiş verilerle doldurulamayan zorunlu alanlar zorunlu olmayan, ancak doğrulama kullanıcıya duyarlı olacak şekilde uygulanmalıdır, böylece geçişten gelen veriler için boş değerlere izin verilir, ancak GUI aracılığıyla normal kullanıcılardan gelen boş değerler reddedilir. .
• Tetikleyiciler, özellikle entegrasyona yeni kayıt gönderenler, entegrasyonun taşınan verilerle taşmasını önlemek için veri taşıma kullanıcısı için açılıp kapatılabilir olmalıdır.

Başka bir numara, taşınan her nesnede alan Eski Kimliği veya Geçiş Kimliği kullanmaktır. Bunun iki nedeni var. Birincisi açık: Eski sistemden ID'yi geri izleme için tutmak; veriler yeni sisteme girdikten sonra, insanlar yine de e-posta, belge ve hata izleme sistemleri gibi yerlerde bulunan eski kimlikleri kullanarak hesaplarında arama yapmak isteyebilir. Kötü alışkanlık? Belki. Ancak eski kimliklerini korursanız kullanıcılar size teşekkür edeceklerdir. İkinci neden tekniktir ve Salesforce'un yeni kayıtlar için (Microsoft Dynamics'in aksine) açıkça sağlanan kimlikleri kabul etmemesi, ancak bunları yükleme sırasında oluşturmasından kaynaklanır. Sorun, alt nesneleri yüklemek istediğimizde ortaya çıkar, çünkü onlara üst nesnelerin kimliklerini atamamız gerekir. Bu kimlikleri ancak yükledikten sonra bileceğimiz için bu boşuna bir alıştırmadır.

Hesapları ve Kişilerini kullanalım, örneğin:

1. Hesaplar için veri oluşturun.
2. Hesapları Salesforce'a yükleyin ve oluşturulan kimlikleri alın.
3. Yeni Hesap Kimliklerini Kişi verilerine dahil edin.
4. Kişiler için veri oluşturun.
5. Kişileri Salesforce'a yükleyin.

Bunu, özel bir harici alanda saklanan Eski Kimliklerine sahip Hesapları yükleyerek daha basit bir şekilde yapabiliriz. Bu alan bir üst referans olarak kullanılabilir, bu nedenle Kişiler'i yüklerken, üst Hesaba bir işaretçi olarak Hesap Eski Kimliğini kullanırız:

1. Eski Kimlik dahil Hesaplar için veri oluşturun.
2. Eski Hesap Kimliği dahil Kişiler için veri oluşturun.
3. Hesapları Salesforce'a yükleyin.
4. Üst referans olarak Hesap Eski Kimliğini kullanarak Kişileri Salesforce'ta yükleyin.

Buradaki güzel şey, daha iyi paralellik, kesinti süresini azaltma vb. için bir nesil ve bir yükleme aşamasını ayırmış olmamızdır.

8. Salesforce'a Özel Özelliklerin Farkında Olun

Herhangi bir sistemde olduğu gibi Salesforce'ta da veri taşıma sırasında hoş olmayan sürprizlerden kaçınmak için farkında olmamız gereken birçok zor kısım vardır. İşte bir avuç örnek:

• Etkin Kullanıcılar üzerindeki bazı değişiklikler, kullanıcı e-postalarına otomatik olarak e-posta bildirimleri oluşturur. Bu nedenle kullanıcı verileriyle oynamak istiyorsak, önce kullanıcıları devre dışı bırakmamız ve değişiklikler tamamlandıktan sonra etkinleştirmemiz gerekiyor. Test ortamlarında, bildirimlerin hiç tetiklenmemesi için kullanıcı e-postalarını karıştırıyoruz. Aktif kullanıcılar maliyetli lisanslar tükettiğinden, tüm test ortamlarında tüm kullanıcıları aktif hale getiremiyoruz. Örneğin, yalnızca bir eğitim ortamındakileri etkinleştirmek için aktif kullanıcıların alt kümelerini yönetmemiz gerekir.
• Hesap veya Vaka gibi bazı standart nesneler için etkin olmayan kullanıcılar, yalnızca "Etkin Olmayan Sahiplerle Kayıtları Güncelle" sistem izni verildikten sonra atanabilir, ancak örneğin Kişilere ve tüm özel nesnelere atanabilirler.
• Kişi devre dışı bırakıldığında, tüm devre dışı bırakma alanları sessizce açılır.
• Yinelenen bir Hesap Ekibi Üyesi veya Hesap Paylaşımı nesnesi yüklerken, mevcut kaydın üzerine sessizce yazılır. Ancak yinelenen bir Fırsat Ortağı yüklenirken, kayıt basitçe eklenir ve bir kopya ile sonuçlanır.
• Created Date , Created By ID , Last Modified Date , Last Modified By ID Göre Son Değiştirme Tarihi gibi sistem alanları, ancak yeni bir sistem izni "Kayıt Oluşturduktan Sonra Denetim Alanlarını Ayarla" verildikten sonra açık bir şekilde yazılabilir.
• Alan geçmişi değer değişiklikleri hiçbir şekilde taşınamaz.
• Bilgi bankası makalelerinin sahipleri, yükleme sırasında belirlenemez ancak daha sonra güncellenebilir.
• İşin zor yanı, içeriğin (belgeler, ekler) Salesforce'ta depolanmasıdır. Bunu yapmanın birden çok yolu vardır (Ekler, Dosyalar, Besleme ekleri, Belgeler kullanarak) ve her yolun farklı dosya boyutu sınırları dahil olmak üzere artıları ve eksileri vardır.
• Seçim listesi alanları, kullanıcıları izin verilen değerlerden birini, örneğin bir hesap türünü seçmeye zorlar. Ancak Salesforce API'sini (veya Apex Data Loader veya Informatica Salesforce bağlayıcısı gibi bunun üzerine kurulu herhangi bir aracı) kullanarak veri yüklerken, herhangi bir değer geçer.

Liste uzayıp gidiyor, ancak sonuç şu: Sisteme aşina olun ve varsayımlarda bulunmadan önce neler yapabileceğini ve neler yapamayacağını öğrenin. Özellikle çekirdek nesneler için standart davranışı varsaymayın. Her zaman araştırın ve test edin.

9. Salesforce'u Veri Taşıma Platformu Olarak Kullanmayın

Salesforce'u, özellikle Salesforce geliştiricileri için bir veri geçişi çözümü oluşturmak için bir platform olarak kullanmak çok caziptir. Salesforce uygulama özelleştirmesi ile veri geçişi çözümü için aynı teknoloji, aynı GUI, aynı Apex programlama dili, aynı altyapı. Salesforce, tablo işlevi görebilen nesnelere ve bir tür SQL dili olan Salesforce Nesne Sorgulama Dili'ne (SOQL) sahiptir. Ancak lütfen kullanmayın; temel bir mimari kusur olurdu.

Salesforce, gelişmiş işbirliği ve zengin özelleştirme gibi pek çok hoş özelliğe sahip mükemmel bir SaaS uygulamasıdır, ancak verilerin toplu olarak işlenmesi bunlardan biri değildir. En önemli üç neden şunlardır:

• Performans – Salesforce'ta verilerin işlenmesi, RDBMS'den birkaç derece daha yavaştır.
• Analitik özelliklerin eksikliği – Salesforce SOQL, Apex dili tarafından desteklenmesi gereken karmaşık sorguları ve analitik işlevleri desteklemez ve performansı daha da düşürür.
• Mimari * – Belirli bir Salesforce ortamına bir veri taşıma platformu yerleştirmek pek uygun değildir. Genellikle, belirli amaçlar için birden fazla ortamımız vardır ve genellikle kod senkronizasyonuna çok zaman ayırabilmemiz için geçici olarak oluşturulur. Ayrıca, söz konusu Salesforce ortamının bağlanabilirliğine ve kullanılabilirliğine de güvenirsiniz.

Bunun yerine, bir RDBMS veya ETL platformu kullanarak ayrı bir örnekte (bulut veya şirket içi olabilir) bir veri geçişi çözümü oluşturun. Kaynak sistemlere bağlayın ve istediğiniz Salesforce ortamlarını hedefleyin, ihtiyacınız olan verileri hazırlama alanınıza taşıyın ve orada işleyin. Bu, şunları yapmanızı sağlayacaktır:

• SQL dilinin veya ETL özelliklerinin tüm gücünden ve özelliklerinden yararlanın.
• Analizleri tüm sistemlerde çalıştırabilmeniz için tüm kod ve verileri tek bir yerde bulundurun.
  • Örneğin, en güncel test Salesforce ortamından en yeni yapılandırmayı, üretim Salesforce ortamından alınan gerçek verilerle birleştirebilirsiniz.
• Kaynak ve hedef sistemlerin teknolojisine çok bağımlı değilsiniz ve çözümünüzü bir sonraki proje için yeniden kullanabilirsiniz.

10. Salesforce Meta Verilerinin Gözetimi

Proje başlangıcında, genellikle Salesforce alanlarının bir listesini alır ve haritalama alıştırmasına başlarız. Proje sırasında, genellikle uygulama geliştirme ekibi tarafından Salesforce'a yeni alanlar eklenir veya bazı alan özellikleri değiştirilir. Uygulama ekibinden veri taşıma ekibini her veri modeli değişikliği hakkında bilgilendirmesini isteyebiliriz, ancak bu her zaman işe yaramaz. Güvende olmak için, tüm veri modeli değişikliklerinin denetim altında olması gerekir.

Bunu yapmanın yaygın bir yolu, Salesforce'tan geçişle ilgili meta verileri düzenli olarak bazı meta veri havuzlarına indirmektir. Buna sahip olduğumuzda, yalnızca veri modelindeki değişiklikleri tespit etmekle kalmaz, aynı zamanda iki Salesforce ortamının veri modellerini karşılaştırabiliriz.

İndirilecek meta veriler:

• Etiketleri, teknik adları ve creatable veya updatable gibi özellikleriyle birlikte nesnelerin listesi.
• Nitelikleriyle birlikte alanların listesi (hepsini almak daha iyidir).
• Seçim listesi alanları için seçim listesi değerlerinin listesi. Doğru değerler için giriş verilerini eşleştirmek veya doğrulamak için onlara ihtiyacımız olacak.
• Yeni doğrulamaların taşınan veriler için sorun yaratmadığından emin olmak için bir doğrulama listesi.

Salesforce'tan meta veriler nasıl indirilir? Standart bir meta veri yöntemi yoktur, ancak birden çok seçenek vardır:

• Enterprise WSDL Oluştur - Salesforce web uygulamasında Setup / API menüsüne gidin ve Salesforce'taki tüm nesneleri ve alanları açıklayan (ancak seçim listesi değerleri veya doğrulamaları değil) kesin yazılan Enterprise WSDL'yi indirin.
• Doğrudan veya Java ya da C# sarmalayıcı kullanarak Salesforce describeSObjects web hizmetini çağırın (Salesforce API'ye danışın). Bu şekilde, ihtiyacınız olanı elde edersiniz ve bu, meta verileri dışa aktarmanın önerilen yoludur.
• İnternette bulunan sayısız alternatif araçtan herhangi birini kullanın.

Sonraki Veri Geçişine Hazırlanın

Salesforce gibi bulut çözümleri anında hazır. Yerleşik işlevlerden memnunsanız, oturum açın ve kullanın. Ancak Salesforce, diğer herhangi bir bulut CRM çözümü gibi, özellikle performans ve kaynak sınırlarıyla ilgili olarak, farkında olunması gereken veri taşıma konularına belirli sorunlar getirir.

Eski verileri yeni sisteme taşımak her zaman bir yolculuktur, bazen geçmiş yıllara ait verilerde gizlenmiş bir geçmişe yolculuktur. Bir düzine taşıma projesine dayanan bu makalede, eski verilerin nasıl taşınacağı ve birçok tuzaktan başarıyla nasıl kaçınılacağı hakkında on ipucu sundum.

Anahtar, verilerin ortaya koyduğu şeyi anlamaktır. Bu nedenle, veri taşıma işlemine başlamadan önce Salesforce geliştirme ekibinizin verilerinizin barındırabileceği olası sorunlar için iyi hazırlandığından emin olun.