Bildiğiniz gibi SAP, hem işlem verilerinin tutulması hem de bu verilerin analiz ve raporlama sistemlerinde işlenmesi için geniş bir yazılım yelpazesi sunmaktadır. Özellikle SAP Business Warehouse (SAP BW) platformu, kapsamlı teknik yeteneklere sahip verileri depolamak ve analiz etmek için bir araç setidir. Tüm objektif avantajlarına rağmen SAP BW sisteminin önemli bir dezavantajı vardır. Bu, özellikle Hana'da bulut tabanlı SAP BW kullanıldığında fark edilen, veri depolama ve işlemenin yüksek maliyetidir.
Depolama olarak SAP olmayan ve tercihen bir Açık Kaynak ürünü kullanmaya başlarsanız ne olur? Biz X5 Perakende Grubu olarak GreenPlum'u seçtik. Bu elbette maliyet sorununu çözüyor, ancak aynı zamanda SAP BW kullanılırken neredeyse varsayılan olarak çözülen sorunlar da hemen ortaya çıkıyor.
Özellikle çoğunluğu SAP çözümü olan kaynak sistemlerden veri nasıl alınır?
HR Metrics bu sorunu çözmenin gerekli olduğu ilk projeydi. Amacımız bir İK verileri deposu oluşturmak ve çalışanlarla çalışma alanında analitik raporlama oluşturmaktı. Bu durumda ana veri kaynağı tüm personel, organizasyon ve maaş faaliyetlerinin yürütüldüğü SAP HCM işlem sistemidir.
Veri çıkarma
SAP BW'de SAP sistemleri için standart veri çıkarıcılar bulunmaktadır. Bu çıkarıcılar gerekli verileri otomatik olarak toplayabilir, bütünlüğünü izleyebilir ve değişiklik deltalarını belirleyebilir. Örneğin, 0EMPLOYEE_ATTR çalışan özelliklerine ilişkin standart veri kaynağı buradadır:
Bir çalışan için ondan veri çıkarmanın sonucu:
Gerekirse böyle bir çıkarıcı, kendi gereksinimlerinize uyacak şekilde değiştirilebilir veya kendi çıkarıcınız oluşturulabilir.
Ortaya çıkan ilk fikir, bunları yeniden kullanma olasılığıydı. Ne yazık ki bunun imkansız bir görev olduğu ortaya çıktı. Mantığın çoğu SAP BW tarafında uygulandı ve kaynaktaki çıkarıcıyı SAP BW'den sorunsuz bir şekilde ayırmak mümkün olmadı.
SAP sistemlerinden veri çekmek için kendi mekanizmamızı geliştirmemiz gerektiği ortaya çıktı.
SAP HCM'de veri depolama yapısı
Böyle bir mekanizmanın gereksinimlerini anlamak için öncelikle hangi verilere ihtiyacımız olduğunu belirlememiz gerekiyor.
SAP HCM'deki çoğu veri düz SQL tablolarında depolanır. SAP uygulamaları bu verilere dayanarak organizasyon yapılarını, çalışanları ve diğer İK bilgilerini kullanıcıya görselleştirir. Örneğin SAP HCM'deki organizasyon yapısı şöyle görünür:
Fiziksel olarak böyle bir ağaç iki tabloda saklanır: hrp1000 nesnelerinde ve hrp1001'de bu nesneler arasındaki bağlantılar.
“Bölüm 1” ve “Ofis 1” Nesneleri:
Nesneler arasındaki ilişki:
Aralarında çok sayıda nesne türü ve bağlantı türü olabilir. Nesneler arasında hem standart bağlantılar hem de kendi özel ihtiyaçlarınıza göre özelleştirilmiş bağlantılar vardır. Örneğin, bir organizasyon birimi ile tam zamanlı bir pozisyon arasındaki standart B012 ilişkisi, bir departmanın başkanını belirtir.
SAP'de yönetici ekranı:
Bir veritabanı tablosunda depolama:
Çalışan verileri pa* tablolarında saklanır. Örneğin, bir çalışanın personel olaylarına ilişkin veriler pa0000 tablosunda saklanır.
GreenPlum'un "ham" verileri almasına karar verdik; bunları SAP tablolarından kopyalamanız yeterli. Ve doğrudan GreenPlum'da işlenecek ve fiziksel nesnelere (örneğin Departman veya Çalışan) ve ölçümlere (örneğin ortalama personel sayısı) dönüştürülecek.
Verilerin GreenPlum'a aktarılması gereken yaklaşık 70 tablo tanımlandı. Daha sonra bu verileri iletmek için bir yöntem geliştirmeye başladık.
SAP oldukça fazla sayıda entegrasyon mekanizması sunmaktadır. Ancak en kolay yol, lisans kısıtlamaları nedeniyle veritabanına doğrudan erişimin yasak olmasıdır. Bu nedenle tüm entegrasyon akışlarının uygulama sunucusu düzeyinde uygulanması gerekir.
Bir sonraki sorun, SAP veritabanında silinen kayıtlarla ilgili veri eksikliğiydi. Veritabanındaki bir satırı sildiğinizde fiziksel olarak silinir. Onlar. değişim zamanına dayalı bir değişim deltasının oluşması mümkün değildi.
Elbette SAP HCM'nin veri değişikliklerini kaydetmeye yönelik mekanizmaları vardır. Örneğin, alıcı sistemlere daha sonra aktarım için, herhangi bir değişikliği kaydeden ve Idoc'un (harici sistemlere aktarım için bir nesne) oluşturulduğu değişiklik işaretçileri vardır.
Personel numarası 0302 olan bir çalışan için 1251445 bilgi tipini değiştirmeye yönelik örnek IDoc:
Veya veri değişikliklerinin günlüklerini DBTABLOG tablosunda tutmak.
Hrp53216375 tablosundan QK1000 anahtarıyla bir kaydı silmek için bir günlük örneği:
Ancak bu mekanizmalar gerekli tüm veriler için mevcut değildir ve bunların uygulama sunucusu düzeyinde işlenmesi oldukça fazla kaynak tüketebilir. Bu nedenle, gerekli tüm tablolarda oturum açma işleminin büyük ölçüde etkinleştirilmesi, sistem performansında gözle görülür bir düşüşe yol açabilir.
Bir sonraki büyük sorun kümelenmiş tablolardı. SAP HCM'nin RDBMS sürümündeki zaman tahmini ve bordro verileri, her hesaplama için her çalışana yönelik bir dizi mantıksal tablo olarak saklanır. Bu mantıksal tablolar pcl2 tablosunda ikili veri olarak saklanır.
Bordro Grubu:
Kümelenmiş tablolardan alınan veriler bir SQL komutu olarak değerlendirilemez ancak SAP HCM makrolarının veya özel işlevsel modüllerin kullanılmasını gerektirir. Buna göre bu tür tabloların okuma hızı oldukça düşük olacaktır. Öte yandan, bu tür kümeler ayda yalnızca bir kez ihtiyaç duyulan verileri (nihai maaş bordrosu ve zaman tahmini) depolar. Yani bu durumda hız o kadar kritik değil.
Veri değişiklikleri deltası oluşturmaya yönelik seçenekleri değerlendirirken, tam boşaltma seçeneğini de değerlendirmeye karar verdik. Gigabaytlarca değişmeden veriyi her gün sistemler arasında aktarma seçeneği iyi görünmeyebilir. Bununla birlikte, bir takım avantajları da vardır; hem deltayı kaynak tarafında uygulamaya hem de bu deltanın alıcı tarafa yerleştirilmesini uygulamaya gerek yoktur. Buna bağlı olarak maliyet ve uygulama süresi azalır, entegrasyonun güvenilirliği artar. Aynı zamanda SAP HR'deki değişikliklerin neredeyse tamamının güncel tarihten önceki üç aylık zaman diliminde gerçekleştiği belirlendi. Bu nedenle, verilerin güncel tarihten N ay önce SAP HR'den günlük olarak tam olarak indirilmesinin ve aylık olarak tam olarak indirilmesinin tercih edilmesine karar verildi. N parametresi belirli tabloya bağlıdır
ve 1'den 15'e kadar değişir.
Veri çıkarma için aşağıdaki şema önerildi:
Harici sistem bir istek oluşturur ve bunu SAP HCM'ye gönderir; burada bu istek, verilerin eksiksizliği ve tablolara erişim izinleri açısından kontrol edilir. Denetim başarılı olursa SAP HCM, gerekli verileri toplayan ve bunları Fuse entegrasyon çözümüne aktaran bir program çalıştırır. Fuse, Kafka'da gerekli konuyu belirler ve verileri oraya aktarır. Daha sonra Kafka'dan gelen veriler Stage Area GP'ye aktarılır.
Bu zincirde SAP HCM'den veri çıkarma konusuyla ilgileniyoruz. Gelin buna daha detaylı bakalım.
SAP HCM-FUSE etkileşim diyagramı.
Harici sistem, SAP'ye yapılan son başarılı isteğin zamanını belirler.
Süreç, SAP'den gelen verilerle yanıt beklemek ve bir tekrar isteği başlatmak için bir zaman aşımı ayarlamak da dahil olmak üzere bir zamanlayıcı veya başka bir olayla başlatılabilir. Daha sonra bir delta isteği oluşturur ve bunu SAP'ye gönderir.
İstek verileri gövdeye json formatında gönderilir.
Yöntem http: POST.
Örnek istek:
SAP hizmeti, talebin eksiksizliğini, mevcut SAP yapısına uygunluğunu ve talep edilen tabloya erişim izninin mevcut olup olmadığını izler.
Hata durumunda hizmet, uygun kod ve açıklamayı içeren bir yanıt döndürür. Kontrol başarılı olursa, bir örnek oluşturmak için bir arka plan işlemi oluşturur, benzersiz bir oturum kimliği oluşturur ve eşzamanlı olarak döndürür.
Bir hata durumunda, harici sistem bunu günlüğe kaydeder. Başarılı bir yanıt durumunda oturum kimliğini ve istekte bulunulan tablonun adını iletir.
Harici sistem mevcut oturumu açık olarak kaydeder. Bu tablo için başka oturumlar varsa, bunlar günlüğe kaydedilen bir uyarıyla kapatılır.
SAP arka plan işi, belirtilen parametrelere ve belirtilen boyutta bir veri paketine dayalı olarak bir imleç oluşturur. Toplu iş boyutu, bir işlemin veritabanından okuduğu maksimum kayıt sayısıdır. Varsayılan olarak 2000'e eşit olduğu varsayılır. Veritabanı örneğinde kullanılan paket boyutundan daha fazla kayıt varsa, ilk paketin iletilmesinden sonra karşılık gelen ofset ve artırılan paket numarasıyla bir sonraki blok oluşturulur. Sayılar 1 artırılarak kesinlikle sıralı olarak gönderilir.
Daha sonra SAP, paketi harici sistemin web servisine girdi olarak iletir. Ve sistem gelen paket üzerinde kontrolleri gerçekleştirir. Alınan id ile bir oturumun sisteme kayıtlı olması ve açık durumda olması gerekmektedir. Paket numarası > 1 ise sistem önceki paketin (paket_id-1) başarıyla alındığını kaydetmelidir.
Kontrol başarılı olursa harici sistem tablo verilerini ayrıştırır ve kaydeder.
Ayrıca pakette son bayrak mevcutsa ve serileştirme başarılıysa, entegrasyon modülüne oturum işlemenin başarıyla tamamlandığı bildirilir ve modül oturum durumunu günceller.
Bir kontrol/ayrıştırma hatası durumunda, hata günlüğe kaydedilir ve bu oturuma ait paketler harici sistem tarafından reddedilir.
Aynı şekilde tam tersi durumda da dış sistem hata döndürdüğünde loglanır ve paket iletimi durdurulur.
SAP HСM tarafında veri talep etmek için bir entegrasyon hizmeti uygulandı. Hizmet, ICF çerçevesinde (SAP İnternet İletişim Çerçevesi - ). Belirli tabloları kullanarak SAP HCM sisteminden veri sorgulamanıza olanak tanır. Bir veri talebi oluştururken, gerekli verileri elde etmek için belirli alanların ve filtreleme parametrelerinin bir listesini belirlemek mümkündür. Aynı zamanda hizmetin uygulanması herhangi bir iş mantığı anlamına gelmez. Delta hesaplama, sorgu parametreleri, bütünlük izleme vb. için algoritmalar da harici sistemin yanında uygulanır.
Bu mekanizma, gerekli tüm verileri birkaç saat içinde toplamanıza ve aktarmanıza olanak tanır. Bu hız kabul edilebilir sınırlarda olduğundan bu çözümü geçici bir çözüm olarak değerlendiriyoruz, bu da projede bir çıkarma aracı ihtiyacını karşılamayı mümkün kıldı.
Hedef resimde veri çıkarma sorununu çözmek için Oracle Golden Gate gibi CDC sistemlerini veya SAP DS gibi ETL araçlarını kullanma seçenekleri araştırılıyor.
Kaynak: habr.com