Düzenle

Aracılığıyla paylaş


Birden çok Power Apps örneği arasında nihai tutarlılık

Microsoft Power Platform
Microsoft Dataverse
Azure Logic Apps

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, dynamics 365 Dataverse varlıklarının bir kısmını tam olarak tümleştirilinceye kadar eşitlenmiş durumda tutmaları gerekir. Conotso'ya özel iş kolu (LOB) uygulaması her iki sistemdeki verileri kullanır ve veriler eşitleme beklerken veya eksik olduğunda istekleri kabul edebilmelidir. Aşağıdaki kılavuzda Power Platform örnekleri arasındaki nihai tutarlılığı hesaba katmanız gösterilmektedir.

Mimari

GUID veya alternatif anahtara göre her zaman upsert eklemek için eklenti/akış

Başarısız bir çoklu sistem eşitlemesine çözüm sağlayan bir dataverse eklentisini gösteren diyagram.

Bu mimarinin bir Visio dosyasını indirin.

İş Akışı

Bu çözüm, eklenti yaşam döngüsü içinde çeşitli eklenti adımları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. Bu, alan zorunluysa tercih edilen seçenektir. Ancak bazı senaryolarda Eklenti Öncesi adımı yeterli olacaktır.

  1. 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 Örneğine ulaşılamıyor.
  2. 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.
  3. 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ş olan yeni bir hesap oluşturulur.
  4. 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 deseni 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. Bununla birlikte, Dataverse örnekleri arasında verileri çoğaltmanın birden çok yolu 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 belirgin olarak genellikle Dataverse varlıklarının bir alt kümesi olarak bulur. 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. Alternatif olarak, 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 de tüketen 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 başvuru verisi toplu işlemini 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 ilgili verileri, ABD örneğinden birincil başvuru anahtarlarını ve Avrupa örneğindeki bilet verilerini çekmek için her iki Dataverse örneğinden kullanıcı verilerini okur. 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 desen aşağıdaki durumlarda yararlı olabilir:

  • Başvuru verilerini gönderen sistem çalışmıyor.
  • Verilerin eşitlenmesi uzun sürer veya işlem gecikir.
  • Tüketen sistemlerin, oluşturulan varlığın oluşturulmasıyla ilgili bir mantığı yoktur.

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 sulanmamış olması sizin için önemli değil.
  • Veriler hala eşitlenmemiş olsa bile oluşturma işlemini kabul etmeniz gerekir.

Bu desen aşağıdaki senaryoda uygun olmayabilir:

  • Kayıt oluşturulduğunda mantık uygulanır. Veriler sulanmayacağı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österilmektedir.

Örnek 1 - Kesinti veya geçici hata olmadan başarılı yol

Başarılı bir çoklu sistem eşitlemesini gösteren diyagram.

Bu mimarinin bir Visio dosyasını indirin.

  1. 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.
  2. 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 amaçlıyor. Ç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

Çok sistemli eşitlemenin başarısız olduğunu gösteren diyagram.

Bu mimarinin bir Visio dosyasını indirin.

  1. 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 Avrupa Örneğine ulaşılamıyor.
  2. 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 amaçlıyor. 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 gereken noktalar

Herhangi bir iş mantığının henüz sulanmamış 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 olacaktır, bu nedenle bu yaklaşımı kullanırken verilerdeki tüm kararların dikkate alındığından emin olmanız gerekir.

Sonraki adımlar

İlgili mimariler:

Web geliştirme kılavuzu: