Bu makalede, ABD merkezli varsayımsal bir müşteri olan Contoso'nun yakın zamanda Avrupa merkezli başka bir şirket satın aldığı ve iki şirket arasında CRM ve ERP sistemleri sürecinde olduğu bir senaryo özetlenmiştir. Bu tümleştirmenin bir parçası olarak, tam olarak tümleştirilebilene kadar Dynamics 365 Dataverse varlıklarının bir kısmını eşitlenmiş durumda tutmaları gerekir. Conotso özel iş kolu (LOB) uygulaması her iki sistemdeki verileri kullanır ve veriler eşitlemeyi beklerken veya eksik olduğunda istekleri kabul edebilmelidir. Aşağıdaki kılavuzda, Power Platform örnekleri arasındaki nihai tutarlılığı hesaba katın.
Mimari
GUID veya alternatif anahtar temelinde her zaman upsert eklemek için eklenti/akış
Bu mimarinin bir Visio dosyasını indirin.
İş akışı
Bu çözüm, eklenti yaşam döngüsü içinde birkaç eklenti adımıyla oluşturulabilir. Oluşturduğunuz varlık zorunlu olduğunda PreValidation adımını kullanın. PreValidation , herhangi bir veritabanı işlemi başlatılmadan önce gerçekleşir. Alan zorunluysa, bu tercih edilen seçenektir. Ancak bazı senaryolarda Bir Ön Oluşturma eklentisi adımı yeterli olacaktır.
- ABD Örneği, bir Mantıksal Uygulama aracılığıyla Avrupa Örneğine yeni bir hesap eşitlemeye çalışır. Kapalı kalma süresi veya yükseltme nedeniyle Europe Instance'a ulaşılamıyor.
- Contoso LOB uygulaması , ABD Örneğindeki ana hesap varlıklarını okur. Avrupa Örneğine çoğaltılmış olmayan bir hesap varlığına başvuran bir API çağrısı göndermeyi amaçlıyor. Bu durumda, eşitleme çalışmadığından kayıt mevcut olmadığından API çağrısı başarısız olur.
- Ancak, PreValidation/PreCreate eklentisi önce sağlanan varlık GUID'sini ve sağlanan başvuru verilerini temel alan bir upsert gerçekleştirir. Zaten varsa, hiçbir şey değiştirilmez. Yoksa, alanların çoğu boş olacak şekilde yeni bir hesap oluşturulur.
- Verilen kimlikli hesap sistemde mevcut olduğundan API çağrısı başarılı olur. Eklenti işlemi durdurdu ve eksik kaydı düzgün bir şekilde işledi. LOB uygulamasından gelen rapor başarıyla oluşturulur.
Not
Microsoft, her iki örneğe başvururken platform kesintilerini işlemek için bu çözümün bir parçası olarak geri dönmek ve yeniden denemek için özel kodunuzda bir devre kesici düzeni eklemenizi önerir. Devre kesici kullanma hakkında daha fazla bilgi için bkz. Devre Kesici Düzeni.
Alternatifler
Yukarıda açıklanan senaryo, çoğaltma yöntemi olarak özel bir Mantıksal Uygulama kullanır. Ancak, Dataverse örnekleri arasında verileri çoğaltmanın çeşitli yolları vardır ve bunlar şunlardır ancak bunlarla sınırlı değildir:
- Logic Apps
- Azure İşlevleri'daki işlev uygulamaları
- Azure Data Factory
- Azure Synapse Analytics
- Power Automate
Senaryo ayrıntıları
Kuruluşlar bazen iki veya daha fazla Power Platform örneğini eşitlenmiş durumda tutma gereksinimini daha açık bir şekilde, genellikle Dataverse varlıklarının bir alt kümesini oluşturur. Bu gereksinim, bir kuruluş coğrafi yalıtım için kasıtlı olarak yeni örnekler eklediğinde ancak tüm coğrafi bölgelerde ortak bir veri kümesine ihtiyaç duyduğunda ortaya çıkar. Öte yandan Power Platform birleştirme işlemi tamamlanmadan önce iki kuruluş birleştirildiğinde de bu durum oluşabilir.
Eşitleme işlemi tasarlandığı gibi çalıştığında, her iki örnekten kullanan iş kolu uygulamalarında sorun olmaz. Ancak, eşitleme mekanizmaları hiçbir zaman hataya dayanıklı değildir, kesintiler veya beklenmeyen sorunlar ortaya çıkabilir. Bu durumda, her iki örnekten de veri kullanan iş kolu uygulamanızın tamamlanmamış verileri işleyecek şekilde derlenmiş olması gerekir.
Contoso'nun yeni Avrupa yan kuruluşunun Contoso'nun iş yapısıyla tümleştirilmesi için, bir Power Platform örneğindeki hesapları ve kişileri başka bir örnekle eşitlemesi gerekir. Bu senaryoda Power Platform'un ABD örneği, özel bir Mantıksal Uygulama aracılığıyla günlük bir toplu başvuru verilerini Avrupa örneğine eşitler. Özel bir Contoso LOB uygulaması, kullanıcıların oluşturduğu sorun biletleriyle ilgili raporlama oluşturur. LoB uygulaması bu görevi tamamlamak için her iki Dataverse örneğinden kullanıcı verilerini okuyarak ilgili verileri, ABD örneğinden birincil başvuru anahtarlarını ve Avrupa örneğinden bilet verilerini çeker. Eşitleme işlemi kapalı kalma süresi, bakım veya başka bir iletişim sorunu nedeniyle tamamlanmamışsa istek, Avrupa örneğindeki varlıkların eksik olması nedeniyle bir hata oluşturur.
Olası kullanım örnekleri
Bu düzen aşağıdaki durumlarda yararlı olabilir:
- Başvuru verilerini gönderen sistem çalışmıyor.
- Verilerin eşitlenmesi uzun sürüyor veya işlem gecikiyor.
- Sistemlerin tüketilmesi, oluşturulan varlığın oluşturulmasıyla ilgili bir mantığa sahip değildir.
Bu yaklaşım ne zaman kullanılır?
Aşağıdaki senaryolarda bu yaklaşımı kullanın:
- Belirli bir anahtara sahip bir kaydın var olduğunu garanti etmek istiyorsunuz ve kaydın tam olarak nemlendirilmesini umursamıyorsunuz.
- Veriler hala eşitlenmemiş olsa bile oluşturma işlemini kabul etmelisiniz.
Bu düzen aşağıdaki senaryoda uygun olmayabilir:
- Kayıt oluşturulduğunda mantık uygulanır. Veriler hidratlanmayacağından, kullanılabilir olan belirli özelliklere güvenmek güvenli değildir.
Örnekler
Aşağıdaki örneklerde olası yolculuklar ve eşitleme gecikmelerinin sonucu gösterilir.
Örnek 1 - Kesinti veya geçici hata içermeyen başarılı yol
Bu mimarinin bir Visio dosyasını indirin.
- ABD Örneği, bir Mantıksal Uygulama aracılığıyla Avrupa Örneğine yeni bir hesap eşitler. Geçici hata veya kesinti oluşmadığından tümü çalışıyor.
- Contoso LOB uygulaması , ABD Örneğindeki ana hesap varlıklarını okur ve Avrupa Örneğine çoğaltılmış bir hesap varlığına başvuran bir API çağrısı göndermeyi hedeflemektedir. Çalışır çünkü her şey çalışır ve hiçbir kesinti veya geçici hata oluşmaz. LOB uygulamasından gelen rapor başarıyla oluşturulur.
Örnek 2 - Eşitlemenin devre dışı veya gecikmeli olduğu başarısız yol
Bu mimarinin bir Visio dosyasını indirin.
- ABD Örneği, bir Mantıksal Uygulama aracılığıyla Avrupa Örneğine yeni bir hesap eşitlemeye çalışır. Kapalı kalma süresi, bakım veya başka bir iletişim sorunu nedeniyle Europe Instance'a ulaşılamıyor.
- Contoso LOB uygulaması , ABD Örneğindeki ana hesap varlıklarını okur ve Avrupa Örneğine çoğaltılmış olmayan bir hesap varlığına başvuran bir API çağrısı göndermeyi hedeflemektedir. Verilen tanımlayıcıya sahip hesap Avrupa Örneğinde oluşturulmadığından ve rapor oluşturulmadığından API çağrısı başarısız olur.
Dikkat edilmesi gerekenler
Herhangi bir iş mantığının henüz hidratlanmamış bir varlık üzerindeki etkisini göz önünde bulundurun. Varlığın henüz tam olarak nemlendirilmediği ve eşitlenmediği bir senaryo düşünün. Bazı özellikler null olur, bu nedenle bu yaklaşımı kullanırken verilerdeki kararların dikkate alındığından emin olmanız gerekir.
Sonraki adımlar
İlgili kaynaklar
İlgili mimariler:
- Microsoft Power Platform için CI/CD
- Power Platform ile Vatandaş yapay zekası
- Büyük ölçekte Power Automate dağıtımı
Web geliştirme kılavuzu: