Như bạn đã biết, SAP cung cấp đầy đủ các phần mềm để duy trì dữ liệu giao dịch và xử lý dữ liệu này trong hệ thống phân tích và báo cáo. Đặc biệt, nền tảng SAP Business Warehouse (SAP BW) là bộ công cụ lưu trữ và phân tích dữ liệu với khả năng kỹ thuật sâu rộng. Đối với tất cả các ưu điểm khách quan của nó, hệ thống SAP BW có một nhược điểm đáng kể. Đây là chi phí lưu trữ và xử lý dữ liệu cao, đặc biệt dễ nhận thấy khi sử dụng SAP BW nền tảng đám mây trên Hana.
Điều gì sẽ xảy ra nếu bạn bắt đầu sử dụng một số sản phẩm không phải SAP và tốt nhất là sản phẩm OpenSource làm bộ lưu trữ? Chúng tôi tại Tập đoàn bán lẻ X5 đã chọn GreenPlum. Tất nhiên, điều này giải quyết được vấn đề chi phí, nhưng đồng thời, các vấn đề ngay lập tức phát sinh đã được giải quyết gần như mặc định khi sử dụng SAP BW.
Đặc biệt, làm thế nào để lấy dữ liệu từ hệ thống nguồn, phần lớn là giải pháp SAP?
HR Metrics là dự án đầu tiên cần thiết để giải quyết vấn đề này. Mục tiêu của chúng tôi là tạo ra một kho lưu trữ dữ liệu nhân sự và xây dựng báo cáo phân tích trong lĩnh vực làm việc với nhân viên. Trong trường hợp này, nguồn dữ liệu chính là hệ thống giao dịch SAP HCM, trong đó mọi hoạt động nhân sự, tổ chức và tiền lương đều được thực hiện.
Trích xuất dữ liệu
Trong SAP BW có các trình trích xuất dữ liệu tiêu chuẩn cho hệ thống SAP. Những trình trích xuất này có thể tự động thu thập dữ liệu cần thiết, theo dõi tính toàn vẹn của nó và xác định các vùng đồng bằng thay đổi. Ví dụ: đây là nguồn dữ liệu tiêu chuẩn cho thuộc tính nhân viên 0EMPLOYEE_ATTR:
Kết quả trích xuất dữ liệu từ nó cho một nhân viên:
Nếu cần, bạn có thể sửa đổi trình trích xuất như vậy để phù hợp với yêu cầu của riêng bạn hoặc có thể tạo trình trích xuất của riêng bạn.
Ý tưởng đầu tiên nảy sinh là khả năng tái sử dụng chúng. Thật không may, điều này hóa ra là một nhiệm vụ bất khả thi. Hầu hết logic được triển khai ở phía SAP BW và không thể tách bộ trích xuất tại nguồn khỏi SAP BW một cách dễ dàng.
Rõ ràng là chúng tôi cần phát triển cơ chế riêng để trích xuất dữ liệu từ hệ thống SAP.
Cấu trúc lưu trữ dữ liệu trong SAP HCM
Để hiểu các yêu cầu đối với cơ chế như vậy, trước tiên chúng ta cần xác định loại dữ liệu nào chúng ta cần.
Hầu hết dữ liệu trong SAP HCM được lưu trữ trong các bảng SQL phẳng. Dựa trên dữ liệu này, các ứng dụng SAP trực quan hóa cơ cấu tổ chức, nhân viên và các thông tin nhân sự khác cho người dùng. Ví dụ: đây là cơ cấu tổ chức trong SAP HCM:
Về mặt vật lý, một cây như vậy được lưu trữ trong hai bảng - trong các đối tượng hrp1000 và trong hrp1001 các kết nối giữa các đối tượng này.
Đối tượng “Sở 1” và “Văn phòng 1”:
Mối quan hệ giữa các đối tượng:
Có thể có một số lượng lớn cả hai loại đối tượng và loại kết nối giữa chúng. Có cả kết nối tiêu chuẩn giữa các đối tượng và kết nối tùy chỉnh cho nhu cầu cụ thể của riêng bạn. Ví dụ: mối quan hệ B012 tiêu chuẩn giữa một đơn vị tổ chức và một vị trí toàn thời gian chỉ ra người đứng đầu bộ phận.
Hiển thị trình quản lý trong SAP:
Lưu trữ trong bảng cơ sở dữ liệu:
Dữ liệu nhân viên được lưu trữ trong bảng pa*. Ví dụ: dữ liệu về các sự kiện nhân sự của một nhân viên được lưu trữ trong bảng pa0000
Chúng tôi đã quyết định rằng GreenPlum sẽ lấy dữ liệu “thô”, tức là chỉ cần sao chép chúng từ bảng SAP. Và trực tiếp trong GreenPlum, chúng sẽ được xử lý và chuyển đổi thành các đối tượng vật lý (ví dụ: Phòng ban hoặc Nhân viên) và các số liệu (ví dụ: số lượng nhân viên trung bình).
Khoảng 70 bảng đã được xác định, dữ liệu từ đó phải được chuyển sang GreenPlum. Sau đó, chúng tôi bắt đầu tìm ra phương pháp truyền dữ liệu này.
SAP cung cấp một số lượng khá lớn các cơ chế tích hợp. Nhưng cách dễ nhất là việc truy cập trực tiếp vào cơ sở dữ liệu bị cấm do hạn chế cấp phép. Vì vậy, tất cả các luồng tích hợp phải được triển khai ở cấp máy chủ ứng dụng.
Vấn đề tiếp theo là thiếu dữ liệu về các bản ghi đã bị xóa trong cơ sở dữ liệu SAP. Khi bạn xóa một hàng trong cơ sở dữ liệu, nó sẽ bị xóa về mặt vật lý. Những thứ kia. việc hình thành một đồng bằng thay đổi dựa trên thời gian thay đổi là không thể.
Tất nhiên, SAP HCM có cơ chế ghi lại những thay đổi của dữ liệu. Ví dụ: đối với lần chuyển tiếp theo sang hệ thống người nhận, có các con trỏ thay đổi ghi lại bất kỳ thay đổi nào và trên cơ sở đó hình thành Idoc (một đối tượng để chuyển sang hệ thống bên ngoài).
Ví dụ IDoc để thay đổi kiểu thông tin 0302 cho nhân viên có mã số nhân sự 1251445:
Hoặc lưu giữ nhật ký thay đổi dữ liệu trong bảng DBTABLOG.
Ví dụ về nhật ký xóa bản ghi có khóa QK53216375 khỏi bảng hrp1000:
Nhưng các cơ chế này không có sẵn cho tất cả dữ liệu cần thiết và việc xử lý chúng ở cấp máy chủ ứng dụng có thể tiêu tốn khá nhiều tài nguyên. Do đó, việc cho phép đăng nhập ồ ạt trên tất cả các bảng cần thiết có thể dẫn đến sự suy giảm đáng kể về hiệu suất hệ thống.
Vấn đề lớn tiếp theo là các bảng phân cụm. Dữ liệu ước tính thời gian và bảng lương trong phiên bản RDBMS của SAP HCM được lưu trữ dưới dạng tập hợp các bảng logic cho mỗi nhân viên cho mỗi phép tính. Các bảng logic này được lưu trữ dưới dạng dữ liệu nhị phân trong bảng pcl2.
Cụm bảng lương:
Dữ liệu từ các bảng được phân cụm không thể được coi là lệnh SQL mà yêu cầu sử dụng macro SAP HCM hoặc các mô-đun chức năng đặc biệt. Theo đó, tốc độ đọc của những bảng như vậy sẽ khá thấp. Mặt khác, các cụm như vậy chỉ lưu trữ dữ liệu cần thiết mỗi tháng một lần - bảng lương cuối cùng và ước tính thời gian. Vì vậy, tốc độ trong trường hợp này không quá quan trọng.
Đánh giá các tùy chọn để hình thành một vùng thay đổi dữ liệu, chúng tôi quyết định cũng xem xét tùy chọn dỡ tải hoàn toàn. Tùy chọn truyền hàng gigabyte dữ liệu không thay đổi giữa các hệ thống mỗi ngày có thể trông không ổn. Tuy nhiên, nó cũng có một số ưu điểm - không cần phải triển khai cả delta ở phía nguồn và triển khai việc nhúng delta này ở phía máy thu. Theo đó, chi phí và thời gian thực hiện giảm xuống, độ tin cậy của việc tích hợp tăng lên. Đồng thời, người ta xác định rằng hầu hết tất cả các thay đổi trong SAP HR đều diễn ra trong khoảng thời gian ba tháng trước ngày hiện tại. Do đó, người ta đã quyết định chọn tải xuống đầy đủ dữ liệu hàng ngày từ SAP HR N vài tháng trước ngày hiện tại và tải xuống đầy đủ hàng tháng. Tham số N phụ thuộc vào bảng cụ thể
và nằm trong khoảng từ 1 đến 15.
Sơ đồ sau đây được đề xuất để trích xuất dữ liệu:
Hệ thống bên ngoài tạo yêu cầu và gửi yêu cầu đó đến SAP HCM, nơi yêu cầu này được kiểm tra tính đầy đủ của dữ liệu và quyền truy cập vào bảng. Nếu kiểm tra thành công, SAP HCM sẽ chạy chương trình thu thập dữ liệu cần thiết và chuyển sang giải pháp tích hợp Fuse. Fuse xác định chủ đề bắt buộc trong Kafka và chuyển dữ liệu đến đó. Tiếp theo, dữ liệu từ Kafka được chuyển sang Stage Area GP.
Trong chuỗi này chúng tôi quan tâm đến vấn đề trích xuất dữ liệu từ SAP HCM. Chúng ta hãy xem xét nó chi tiết hơn.
Sơ đồ tương tác SAP HCM-FUSE.
Hệ thống bên ngoài xác định thời điểm yêu cầu thành công cuối cùng tới SAP.
Quá trình này có thể được khởi chạy bằng đồng hồ hẹn giờ hoặc sự kiện khác, bao gồm đặt thời gian chờ để chờ phản hồi với dữ liệu từ SAP và bắt đầu yêu cầu lặp lại. Sau đó, nó tạo ra một yêu cầu delta và gửi nó đến SAP.
Dữ liệu yêu cầu được gửi đến nội dung ở định dạng json.
Phương thức http: POST.
Yêu cầu ví dụ:
Dịch vụ SAP giám sát yêu cầu về tính đầy đủ, tuân thủ cấu trúc SAP hiện tại và tính khả dụng của quyền truy cập vào bảng được yêu cầu.
Trong trường hợp có lỗi, dịch vụ sẽ trả về phản hồi với mã và mô tả thích hợp. Nếu điều khiển thành công, nó sẽ tạo một quy trình nền để tạo mẫu, tạo và trả về một cách đồng bộ một id phiên duy nhất.
Trong trường hợp có lỗi, hệ thống bên ngoài sẽ ghi lại vào nhật ký. Trong trường hợp phản hồi thành công, nó sẽ truyền id phiên và tên của bảng mà yêu cầu được thực hiện.
Hệ thống bên ngoài đăng ký phiên hiện tại là mở. Nếu có các phiên khác cho bảng này, chúng sẽ bị đóng bằng một cảnh báo được ghi lại.
Công việc nền SAP tạo ra một con trỏ dựa trên các tham số đã chỉ định và gói dữ liệu có kích thước đã chỉ định. Kích thước lô là số lượng bản ghi tối đa mà một tiến trình đọc từ cơ sở dữ liệu. Theo mặc định, nó được giả định bằng 2000. Nếu có nhiều bản ghi trong mẫu cơ sở dữ liệu hơn kích thước gói đã sử dụng, sau khi truyền gói đầu tiên, khối tiếp theo sẽ được hình thành với số gói tăng dần và bù đắp tương ứng. Các số được tăng thêm 1 và được gửi theo đúng tuần tự.
Tiếp theo, SAP chuyển gói này làm đầu vào cho dịch vụ web của hệ thống bên ngoài. Và hệ thống thực hiện các điều khiển trên gói tin đến. Phiên có id nhận được phải được đăng ký trong hệ thống và nó phải ở trạng thái mở. Nếu số gói > 1, hệ thống sẽ ghi lại việc nhận thành công gói trước đó (gói_id-1).
Nếu điều khiển thành công, hệ thống bên ngoài sẽ phân tích cú pháp và lưu dữ liệu bảng.
Ngoài ra, nếu cờ cuối cùng xuất hiện trong gói và việc tuần tự hóa thành công thì mô-đun tích hợp sẽ được thông báo về việc hoàn tất xử lý phiên thành công và mô-đun sẽ cập nhật trạng thái phiên.
Trong trường hợp xảy ra lỗi điều khiển/phân tích cú pháp, lỗi sẽ được ghi lại và các gói cho phiên này sẽ bị hệ thống bên ngoài từ chối.
Tương tự, trong trường hợp ngược lại, khi hệ thống bên ngoài trả về lỗi, nó sẽ được ghi lại và quá trình truyền gói sẽ dừng.
Để yêu cầu dữ liệu từ phía SAP HСM, một dịch vụ tích hợp đã được triển khai. Dịch vụ này được triển khai trên khung ICF (Khuôn khổ truyền thông Internet SAP - ). Nó cho phép bạn truy vấn dữ liệu từ hệ thống SAP HCM bằng các bảng cụ thể. Khi tạo yêu cầu dữ liệu, có thể chỉ định danh sách các trường cụ thể và tham số lọc để có được dữ liệu cần thiết. Đồng thời, việc triển khai dịch vụ không bao hàm bất kỳ logic kinh doanh nào. Các thuật toán tính toán delta, tham số truy vấn, giám sát tính toàn vẹn, v.v. cũng được triển khai ở phía hệ thống bên ngoài.
Cơ chế này cho phép bạn thu thập và truyền tất cả dữ liệu cần thiết trong vài giờ. Tốc độ này gần như có thể chấp nhận được, vì vậy chúng tôi coi giải pháp này là giải pháp tạm thời, giúp đáp ứng nhu cầu về một công cụ trích xuất trong dự án.
Trong bức tranh mục tiêu, để giải quyết vấn đề trích xuất dữ liệu, các phương án sử dụng hệ thống CDC như Oracle Golden Gate hoặc các công cụ ETL như SAP DS đang được khám phá.
Nguồn: www.habr.com