Giải thích kiến trúc tích hợp Power Apps với SAP S/4HANA On-Premise
1. Mục tiêu của kiến trúc
Kiến trúc này được thiết kế để giải quyết một bài toán rất phổ biến trong doanh nghiệp:
- phía business cần một lớp ứng dụng hiện đại, linh hoạt, giao diện tốt để người dùng vận hành hàng ngày
- phía back-end vẫn là SAP S/4HANA On-Premise, nơi lưu giữ dữ liệu nghiệp vụ cốt lõi và thực hiện hạch toán chính thức
- cần kết nối hai thế giới này với nhau theo cách:
- an toàn
- kiểm soát được
- mở rộng được
- không làm ảnh hưởng trực tiếp tới SAP On-Premise
Nói ngắn gọn, kiến trúc này tách hệ thống thành 3 lớp lớn:
- Lớp trải nghiệm và ứng dụng nghiệp vụ trên Power Platform
- Lớp tích hợp trung gian để kiểm soát kết nối, mapping và orchestration
- Lớp SAP On-Premise là hệ thống tài chính và nghiệp vụ lõi
2. Tổng quan các khối trong sơ đồ
Sơ đồ có thể được hiểu theo chiều từ trái sang phải:
Bên trái: Microsoft Power Platform
Đây là nơi người dùng tương tác.
Bao gồm:
- Power Apps
- Power Automate
- Power BI
- Dataverse
Ở giữa: Integration Layer On-Premise
Đây là lớp trung gian, đóng vai trò cầu nối giữa cloud và SAP on-prem.
Bao gồm:
- On-Premise Data Gateway
- Integration Server
- API / Connector / Mapping / Transformation
- Secure Connectivity
Bên phải: SAP S/4HANA On-Premise
Đây là hệ thống lõi đang chạy trong data center nội bộ.
Bao gồm:
- MM
- FI
- FM
- Master Data
- SAP HANA Database
Dưới cùng: Supporting Services
Đây là các thành phần hỗ trợ hạ tầng và vận hành:
- AD/SSO
- Security
- Audit & Logging
- Backup & Recovery
- Monitoring
3. Giải thích chi tiết từng lớp
3.1. User Layer
Nhóm người dùng ở cột ngoài cùng bên trái cho thấy hệ thống không phục vụ chỉ một nhóm duy nhất. Nó phục vụ nhiều vai trò khác nhau:
- Project Managers
- Cost Controllers
- Finance / AP Users
- Executives
- External Contractors
Ý nghĩa thiết kế ở đây là:
- cùng một nền tảng, nhưng mỗi vai trò sẽ nhìn thấy chức năng khác nhau
- Power Apps có thể dựng nhiều màn hình, form, rule và phân quyền theo role
- Executive có thể chỉ cần dashboard
- PM có thể cần contract, acceptance, payment request
- Finance cần approval, invoice, payment status
- contractor bên ngoài nếu có scope tương lai thì có thể dùng portal riêng
Tức là kiến trúc này hỗ trợ mô hình role-based experience chứ không phải một ứng dụng đồng nhất cho tất cả.
3.2. Microsoft Power Platform
Đây là lớp front-end và application platform.
a. Power Apps
Đây là ứng dụng nghiệp vụ chính.
Trong sơ đồ, Power Apps đang được định vị là nơi xử lý:
- Project Management
- Cost Management
- Budget Management
- Contract Management
- Acceptance & Payment
- Dashboard & Reporting
Nghĩa là Power Apps không chỉ là form nhập liệu đơn giản. Nó là lớp ứng dụng nghiệp vụ vận hành.
Vai trò cụ thể:
- thu thập dữ liệu từ người dùng
- chuẩn hóa dữ liệu đầu vào
- chạy business logic mức ứng dụng
- trigger workflow
- hiển thị trạng thái dữ liệu từ SAP
- làm lớp operational system cho người dùng cuối
b. Power Automate
Dùng cho workflow và orchestration nhẹ.
Ví dụ:
- phê duyệt budget
- phê duyệt payment request
- gửi thông báo khi trạng thái SAP thay đổi
- chạy các luồng đồng bộ định kỳ
- escalation khi quá hạn
Điểm quan trọng là Power Automate phù hợp cho workflow nghiệp vụ, nhưng không nên là nơi xử lý integration nặng với SAP theo kiểu mission-critical. Vì vậy trong sơ đồ, Power Automate nằm ở lớp ứng dụng, còn integration nặng vẫn đẩy qua lớp trung gian.
c. Power BI
Đây là lớp báo cáo.
Vai trò:
- dashboard quản trị
- phân tích budget vs actual
- báo cáo contract, payment, commitment
- phục vụ lãnh đạo và finance
Điểm hay là Power BI có thể lấy dữ liệu từ Dataverse, từ data mart, hoặc từ dữ liệu đồng bộ từ SAP.
d. Dataverse
Đây là nơi lưu trữ dữ liệu ứng dụng.
Vai trò:
- lưu dữ liệu nghiệp vụ của Power Apps
- lưu master data phục vụ vận hành
- lưu transaction trước/sau khi tích hợp SAP
- lưu trạng thái workflow
- lưu data trung gian để reporting
Dataverse không thay SAP. Dataverse đóng vai trò operational store cho Power Apps.
4. Vì sao không kết nối Power Apps trực tiếp vào SAP On-Premise?
Đây là một trong những điểm quan trọng nhất của thiết kế.
Về mặt kỹ thuật, nhiều người sẽ hỏi:
Tại sao không cho Power Apps gọi thẳng SAP?
Câu trả lời là vì cách đó thường không tốt cho hệ thống enterprise.
Nếu gọi thẳng:
- khó kiểm soát bảo mật
- khó mapping phức tạp
- khó retry / error handling
- khó monitoring
- khó thay đổi khi interface SAP đổi
- dễ phụ thuộc trực tiếp vào cấu trúc kỹ thuật của SAP
Khi có Integration Layer:
- Power Apps chỉ nói chuyện với một lớp API / service thống nhất
- SAP được bảo vệ phía sau firewall
- business logic tích hợp được tập trung
- có thể log, monitor, retry, transform dữ liệu
- dễ scale hơn khi sau này tích hợp thêm hệ thống khác
Vì vậy lớp Integration Layer là cực kỳ quan trọng.
5. Integration Layer On-Premise
Đây là phần trung tâm của toàn bộ thiết kế.
5.1. On-Premise Data Gateway
Đây là cổng kết nối an toàn giữa Power Platform và hệ thống nội bộ.
Vai trò:
- cho phép cloud service của Microsoft truy cập tài nguyên on-prem một cách bảo mật
- tránh phải mở trực tiếp SAP ra internet
- giữ kết nối outbound từ nội bộ ra ngoài, thay vì inbound nguy hiểm từ internet vào trong
Nó là một thành phần nền tảng rất quan trọng nếu bạn dùng Power Apps / Power BI / Power Automate mà cần truy cập hệ thống on-prem.
Tuy nhiên, gateway không nên bị hiểu là “giải pháp tích hợp hoàn chỉnh”. Nó chỉ là cánh cửa bảo mật. Business integration thực sự vẫn cần một lớp service phía sau nó.
5.2. Integration Server
Đây là não bộ của lớp tích hợp.
Trong sơ đồ, server này chứa:
- API Management / Reverse Proxy
- Logic Apps / Custom Connectors
- Mapping & Transformation
Tức là tất cả luồng từ Power Platform đi vào SAP sẽ được xử lý qua server này.
Vai trò chính:
- Expose API nội bộ
- Power Apps gọi API của integration server
- không gọi trực tiếp SAP
- Transform dữ liệu
- đổi format từ Power Apps sang format SAP
- đổi response SAP thành format dễ dùng cho app
- Validation
- kiểm tra mandatory field
- kiểm tra mapping code
- kiểm tra trạng thái trước khi post SAP
- Orchestration
- 1 request từ app có thể gọi nhiều bước SAP
- ví dụ tạo payment request, check master, tạo AP invoice, cập nhật status
- Error handling
- retry
- log lỗi
- trả message thân thiện về app
- Monitoring
- biết request nào thành công
- request nào fail
- SAP phản hồi thế nào
- có nghẽn performance hay không
5.3. API Management / Reverse Proxy
Nếu doanh nghiệp muốn làm bài bản hơn, cần có API layer rõ ràng.
Vai trò:
- publish API chuẩn cho Power Apps
- giới hạn truy cập
- authen / autho
- rate limit
- log request / response
- versioning API
Điều này giúp về lâu dài:
- app không bị phụ thuộc vào chi tiết SAP
- nhiều app có thể reuse cùng service
- sau này dễ thay đổi backend
5.4. Logic Apps / Custom Connectors
Tùy chọn này dùng khi muốn kết nối Power Platform với hệ thống ngoài.
- Custom Connector: phù hợp để Power Apps gọi service do bạn tự viết
- Logic Apps: phù hợp orchestration cloud-based
- Nếu doanh nghiệp cần kiểm soát on-prem chặt hơn, có thể thay bằng custom API service trên Windows Server / IIS
Tức là ô này trong sơ đồ không nhất thiết là một sản phẩm duy nhất, mà là “khả năng tích hợp”.
5.5. Mapping & Transformation
Đây là phần cực kỳ quan trọng trong tích hợp SAP.
Vì dữ liệu giữa Power Apps và SAP sẽ không giống nhau hoàn toàn.
Ví dụ:
- Project trong app có thể map sang Fund Center hoặc coding block trong SAP
- Cost type trong app map sang Commitment Item
- Payment Request trong app map sang AP Invoice / Payment proposal trong SAP
- Contract trong app map sang Service PO trong MM
Nếu không có lớp mapping rõ:
- dữ liệu sẽ lộn xộn
- khó maintain
- rất dễ sai hạch toán
Đây chính là lý do lớp tích hợp phải có rule mapping tập trung.
6. Secure Connectivity
Ở phần dưới của Integration Layer, sơ đồ nêu ra các phương án kết nối an toàn với SAP:
- SAP Cloud Connector
- SAP PI/PO hoặc SAP Integration Suite bản on-prem
- OData / SOAP / RFC / IDoc
Điều này cho thấy thiết kế đang để mở nhiều phương án kỹ thuật.
Ý nghĩa:
Không khóa vào một connector duy nhất. Tùy landscape SAP hiện hữu, bạn có thể chọn cách phù hợp.
a. OData / SOAP
Phù hợp nếu SAP đã expose service chuẩn.
b. RFC / IDoc
Phù hợp khi cần tích hợp theo kiểu SAP truyền thống.
c. SAP PI/PO
Phù hợp nếu khách hàng đã có middleware SAP chuẩn doanh nghiệp.
d. SAP Cloud Connector
Phù hợp trong bối cảnh hybrid nhưng vẫn muốn kết nối bảo mật.
Nói cách khác, sơ đồ đang thể hiện một integration pattern mở, không quá phụ thuộc một sản phẩm cụ thể.
7. SAP S/4HANA On-Premise
Bên phải là SAP core.
7.1. MM – Materials Management
Trong sơ đồ, MM đang xử lý:
- Purchase Requisition
- Purchase Order
- Goods Receipt
Với scope dự án của bạn, phần này thường tương ứng:
- PR/PO dịch vụ
- nghiệm thu dịch vụ dạng Service Entry / GR
- quản lý vendor side của procurement
Power Apps sẽ không thay MM. Nó chỉ chuẩn bị dữ liệu và gửi dữ liệu sang MM.
7.2. FI – Financial Accounting
FI xử lý:
- AP Invoice
- Vendor master liên quan
- G/L account
- Payment
Nghĩa là các nghiệp vụ tài chính chính thức vẫn ở SAP:
- post hóa đơn
- hạch toán phải trả
- thanh toán
- sổ cái
App không được phép thay vai trò này nếu muốn đảm bảo control tài chính.
7.3. FM – Funds Management
FM xử lý:
- Budget
- Commitment
- Actuals
- Funds check
Đây là nơi quan trọng nhất nếu bài toán của bạn là budget control.
Tức là:
- app lập budget, quản lý chi tiết
- SAP FM giữ ngân sách chính thức và check control
- commitment từ PO
- actual từ invoice/payment
Nhờ đó Power Apps có thể làm lớp early warning, còn SAP làm hard control.
7.4. Master Data
Bao gồm:
- Cost center
- Vendor
- Material
- WBS / Project hoặc coding structure
- payment term
- các master khác
Phần này rất quan trọng vì nếu master data không thống nhất thì tích hợp sẽ fail.
8. SAP HANA Database
Database nằm phía sau SAP.
Nó không được app truy cập trực tiếp.
Vai trò của nó chỉ để nhấn mạnh:
- SAP là hệ thống lõi có persistence riêng
- mọi transaction cuối cùng vẫn nằm trong SAP
- Power Apps không bypass application layer của SAP để ghi thẳng DB
Đây là nguyên tắc rất đúng.
9. Data flow trong kiến trúc này
Sơ đồ có 3 loại luồng chính.
9.1. User access flow
Người dùng vào Power Apps qua web/mobile.
Đây là lớp trải nghiệm.
9.2. Data / integration flow
Dữ liệu đi từ Power Apps → integration → SAP và ngược lại.
9.3. Control / management flow
Monitoring, logging, admin, workflow, auth.
10. Luồng nghiệp vụ mẫu
10.1. Budget setup
- User lập budget trong Power Apps
- Dữ liệu vào Dataverse
- Power Apps / flow gửi budget sang integration layer
- Integration layer map sang structure SAP FM
- SAP FM cập nhật budget
- Kết quả trả lại app
10.2. Payment request
- PM tạo payment request trong app
- Workflow duyệt nội bộ
- Integration layer validate contract / vendor / amount
- Gửi sang SAP FI/MM
- SAP tạo invoice/payment-related transaction
- Status trả về app
10.3. Actual sync
- Invoice/payment phát sinh trong SAP
- Integration layer lấy actual/commitment
- Đẩy về Dataverse
- Dashboard app cập nhật Budget vs Actual vs Commitment
11. Supporting Services
Đây là phần nhiều người hay bỏ qua nhưng thực ra rất quan trọng.
Active Directory / SSO
- đăng nhập một lần
- đồng nhất user nội bộ
- phân quyền theo role
Security
- role & authorization
- ai xem được gì
- ai tạo / duyệt / sửa
Audit & Logging
- log kỹ thuật
- log nghiệp vụ
- trace giao dịch
- audit trail cho tài chính
Backup & Recovery
- backup cho integration service, config, data store phụ trợ
- phương án khôi phục khi lỗi
Monitoring
- monitor sức khỏe service
- monitor tích hợp fail/success
- alert khi SAP không phản hồi
Phần này rất quan trọng nếu muốn hệ thống chạy production thực sự.
12. Điểm mạnh của kiến trúc này
12.1. Không ép người dùng làm việc trực tiếp trên SAP
Người dùng vận hành trên Power Apps, thân thiện hơn, linh hoạt hơn.
12.2. Vẫn giữ SAP là hệ thống chuẩn
SAP vẫn là nơi:
- hạch toán
- kiểm soát ngân sách
- lưu transaction chính thức
12.3. Tách lớp rõ ràng
- app
- integration
- SAP
- infra support
Nên dễ quản lý hơn.
12.4. Mở rộng tốt
Sau này có thể thêm:
- contractor portal
- thêm report
- thêm mobile
- thêm hệ khác ngoài SAP
mà không cần phá cấu trúc lõi.
13. Những điểm cần lưu ý khi triển khai thực tế
13.1. Đừng để Power Automate gánh toàn bộ integration nặng
Workflow thì được, nhưng SAP mission-critical nên có integration service riêng.
13.2. Mapping rule phải được chốt rất sớm
Ví dụ:
- Project ↔ Fund Center
- Cost Type ↔ Commitment Item
- Contract ↔ PO
- Payment Request ↔ AP Invoice
Nếu chốt trễ thì dự án rất dễ trượt.
13.3. Phải rõ ownership master data
Ai tạo vendor?
Ai chuẩn hóa material/service?
Ai quản lý code map?
Nếu không rõ sẽ sinh lỗi tích hợp liên tục.
13.4. Cần log và reconciliation
Không thể chỉ “gửi xong là thôi”.
Phải có:
- trạng thái gửi
- trạng thái nhận
- lỗi
- retry
- đối soát
13.5. Không coi gateway là integration architecture
Gateway chỉ là đường kết nối, không phải giải pháp tích hợp hoàn chỉnh.
14. Kết luận
Kiến trúc này đang đi theo mô hình rất hợp lý cho doanh nghiệp có SAP On-Premise:
- Power Apps làm lớp ứng dụng nghiệp vụ hiện đại cho người dùng
- Integration Layer làm lớp điều phối, mapping và bảo vệ hệ thống
- SAP S/4HANA On-Premise tiếp tục đóng vai trò hệ thống lõi cho tài chính và nghiệp vụ chính thức
Nói cách khác, đây là kiến trúc:
Modern operational front-end + controlled integration layer + stable SAP core
Đó là mô hình rất phù hợp khi doanh nghiệp muốn:
- số hóa quy trình nhanh
- không thay thế SAP
- vẫn kiểm soát tài chính chặt
- và có thể mở rộng dần theo từng phase
