ServiceNow cho FDE: Integration Hub, Scripted REST và MID Server ở khách doanh nghiệp lớn

Đến ngày thứ ba ở khách, bạn mới phát hiện cơ sở dữ liệu tài sản mà agent cần đọc nằm trong mạng nội bộ, còn instance ServiceNow thì chạy trên cloud. Bản demo chạy ngon trên laptop lúc đó không còn giúp được gì. Câu hỏi giờ là làm sao cho hai bên nói chuyện được với nhau, theo cách mà đội bảo mật của ngân hàng chấp nhận.

ServiceNow tự nhận 85% Fortune 500 là khách hàng của họ. Nếu bạn làm FDE cho doanh nghiệp lớn, khả năng cao bạn sẽ gặp một instance ServiceNow nằm đâu đó trên đường đi của dữ liệu.

Có ba công cụ quyết định tích hợp đó chạy được tới production hay không: hai công cụ lo hướng đi của dữ liệu, công cụ thứ ba lo chuyện hệ thống đích nằm ở đâu.

Hỏi trước: dữ liệu đi hướng nào, và nằm ở đâu?

Cách phân vai đơn giản nhất như sau. Khi hệ thống của bạn cần gọi vào ServiceNow, bạn viết Scripted REST API. Khi ServiceNow cần gọi ra ngoài, bạn dùng spoke của Integration Hub.

Nhu cầu ở khách	Công cụ	Điều cần nhớ
Hệ thống ngoài gọi vào ServiceNow	Scripted REST API	Version trong URI; thay đổi lớn thì tạo version mới trước
ServiceNow gọi ra hệ thống khác	Spoke của Integration Hub	Bước bản ghi chạy trên instance, bước gọi mạng khách chạy trên MID
Hệ thống đích nằm trong mạng khách	MID Server	Nguồn JDBC, LDAP, export set dùng MID riêng

MID Server: người gác cổng nằm trong mạng khách

Tài liệu chính thức của ServiceNow mô tả MID Server là điểm trung gian giữa mạng của khách và instance. Khi ngồi với đội bảo mật của khách, hãy lấy chính mô tả này làm điểm xuất phát để vẽ luồng dữ liệu đi qua đâu, rồi cùng họ xác nhận cụ thể những kết nối nào cần được cho phép.

Ở production, một MID Server đơn lẻ là điểm lỗi duy nhất: nó chết là cả luồng dừng. Cluster failover giải quyết chuyện này bằng một thứ tự cấu hình sẵn để biết khi có sự cố sẽ chuyển sang MID Server nào tiếp theo.

Cái giá của cluster là rủi ro trùng dữ liệu. Sau failover, tác vụ trong ECC queue chạy lại từ đầu, nên một lần đọc JDBC dở dang có thể được ghi hai lần. Cluster cũng không hỗ trợ các ECC queue topic Command và SystemCommand.

Integration Hub: khi nào bạn cần một spoke?

Integration Hub là công cụ low-code trên Now Platform, mở rộng Flow Designer để tích hợp với API bên thứ ba. Về chi phí, Perspectium cho biết giá tính theo lượng transaction và số spoke, và gói Starter miễn phí có giới hạn 1.000.000 transaction mỗi năm. Hãy đối chiếu con số này với license thực tế của khách trước khi hứa về khối lượng.

Phần lớn thời gian, bạn sẽ làm việc với spoke. Mỗi spoke gom các action, subflow và file hỗ trợ có liên quan vào một chỗ, để kết nối với một hệ thống cụ thể. Thử hình dung khách cần ServiceNow tra và cập nhật kho tài sản nội bộ.

Thay vì rải các bước REST lẻ tẻ khắp nhiều flow, bạn gom “tra tài sản theo mã” và “cập nhật trạng thái” vào một spoke “Kho tài sản” để mọi flow dùng chung.

Vì kho tài sản nằm trong mạng khách, bước gọi tới nó chạy trên MID Server, còn bước ghi kết quả vào bản ghi chạy trên instance. ServiceNow khuyên tránh chuyển môi trường chạy qua lại nhiều lần. Trong ví dụ này, hãy để MID Server làm xong mọi việc với kho tài sản rồi trả kết quả về một lần.

Scripted REST: cánh cửa cho agent của bạn

Chiều ngược lại, khi agent hay dịch vụ của bạn cần tạo hoặc đọc bản ghi, Scripted REST API cho bạn tự xây web service theo ý mình. Điểm đáng giá nhất là số version nằm ngay trong URI, nên bạn thử và phát hành thay đổi mà không đụng tới các tích hợp đang chạy.

Quy tắc của ServiceNow rất rõ: khi có thay đổi lớn về chức năng, tạo version mới trước. Ở doanh nghiệp lớn, một endpoint có thể có nhiều đội gọi, và bạn thường không biết hết họ là ai.

Bốn lỗi làm tích hợp gãy ở production

Lỗi đầu tiên: ném MID Server đọc JDBC vào cluster cho “chắc ăn”. ServiceNow khuyên dùng MID Server riêng, không cluster, cho các nguồn LDAP, export set và JDBC, chính vì rủi ro trùng dữ liệu sau failover.

Lỗi thứ hai: phát hành endpoint không có version, rồi sửa thẳng hành vi của bản đang chạy. Client của đội khác gãy mà bạn không hề hay biết.

Lỗi thứ ba: flow nhảy qua lại giữa instance và MID Server nhiều lần, thứ ServiceNow khuyên tránh. Lỗi thứ tư: đẩy khối dữ liệu lớn qua Integration Hub. Perspectium cảnh báo việc này có thể làm nền tảng ServiceNow chậm thấy rõ, và người chịu trận là mọi người dùng khác trên instance của khách.

Ghép lại thành một ca cụ thể

Thử hình dung luồng hoàn chỉnh. Agent gọi endpoint v1 để mở incident, rồi một flow gọi spoke action tra tài sản trong cơ sở dữ liệu nội bộ. Action đó chạy trên một MID Server riêng dành cho JDBC, làm xong phần việc trong mạng khách rồi mới trả kết quả về instance.

Muốn học, hãy bắt đầu bằng Scripted REST trên một instance cá nhân, vì đó là phần gần nhất với kỹ năng backend bạn đã có. Sau đó học tới spoke, cuối cùng là MID Server.

Trong CV, đừng chỉ ghi “đã làm ServiceNow”.

Hãy viết một dòng cụ thể, chẳng hạn: “Xây Scripted REST API có version (v1, v2) cho agent tạo incident; tra cơ sở dữ liệu tài sản nội bộ qua JDBC trên MID Server riêng, không cluster.” Khi đọc tin tuyển FDE cho khách doanh nghiệp, để ý xem họ có nhắc tới ServiceNow hay hệ thống nội bộ không, rồi đưa đúng dòng đó lên đầu.

Người đánh giá bạn ở khách lớn ít khi hỏi agent thông minh đến đâu. Họ hỏi nó có đi qua được firewall mà không làm trùng một dòng dữ liệu nào không.