Một đơn vị có phần mềm tài sản, bản đồ GIS và công cụ lập báo cáo. Cả ba đều dùng thông tin về đèn đường, nhưng mỗi nơi giữ một bảng dữ liệu riêng. Khi vị trí của một đèn được sửa, người làm lại phải nhớ chuyển thông tin sang hai nơi còn lại.

Kết nối phần mềm có thể giảm việc chép lại này. Tuy nhiên, trước khi trao đổi dữ liệu tự động, các hệ thống cần hiểu chúng đang nói về cùng tài sản và thông tin nào được phép lấy từ đâu.

Một mã nhận diện và nơi chịu trách nhiệm

Trong ví dụ giả định, GIS quản lý vị trí, còn phần mềm tài sản giữ hồ sơ bảo trì. Khi người dùng chọn đèn trên bản đồ, GIS có thể lấy thêm thông tin bảo trì từ nguồn đó thay vì yêu cầu nhập lại.

Mã chung như D-017 giúp nối hai nguồn. Nếu mỗi bên có mã riêng, một bảng ghép mã đã được kiểm tra có thể giữ mối liên hệ. Tên giống nhau hoặc vị trí gần nhau chỉ hỗ trợ đối chiếu, chưa đủ để tự xác nhận đó là cùng một đèn.

Trách nhiệm về từng trường cũng cần rõ. Khi cả hai phần mềm đều sửa được vị trí mà chưa có quy tắc giải quyết khác biệt, trao đổi tự động có thể làm mâu thuẫn lan nhanh hơn. Với tài sản ngừng sử dụng, các nơi liên quan còn cần nhận trạng thái này và giữ được lịch sử, thay vì chỉ nhận danh sách tài sản đang hoạt động.

API giúp phần mềm hỏi và nhận thông tin

API có thể hiểu là cách một phần mềm gửi yêu cầu cho phần mềm khác theo quy ước. Chẳng hạn, GIS hỏi hồ sơ bảo trì của đèn D-017 và nhận các trường được phép cung cấp, như ngày sửa gần nhất và tình trạng xử lý.

Người sử dụng không phải mở phần mềm bên kia để chép từng dòng, nhưng nhóm thực hiện vẫn phải thống nhất mã, tên trường, định dạng ngày và cách phản hồi khi không tìm thấy hồ sơ. Quyền truy cập cũng phải theo người dùng hoặc hệ thống được phép nhận thông tin.

Thống nhất dữ liệu trao đổi trước khi nối hệ thống

Một mô tả trao đổi tối thiểu cần nói rõ mã đối tượng, ý nghĩa trường, hệ tọa độ của hình học, thời điểm dữ liệu và cách báo lỗi. Nếu kết quả được chia thành nhiều trang, bên nhận phải đọc đủ các trang cần thiết, không coi trang đầu là toàn bộ danh sách. Nếu nhận thay đổi theo đợt, phải biết cách nhận cả đối tượng ngừng sử dụng hoặc bị xóa theo quy ước.

OGC API — Features cung cấp cách truy cập đối tượng địa lý theo chuẩn; phần Core tập trung vào đọc dữ liệu. Việc cập nhật, duyệt thay đổi và đồng bộ giữa các ứng dụng vẫn cần thiết kế riêng. Dùng API cũng không có nghĩa công khai toàn bộ dữ liệu: máy chủ phải kiểm tra quyền ở từng yêu cầu, kể cả khi người dùng gọi trực tiếp ngoài giao diện bản đồ.

Không phải mọi nơi đều đổi cùng lúc

Có nơi hỏi dữ liệu khi mở hồ sơ, có nơi nhận theo lịch. Một báo cáo đã chốt còn có thể cần giữ số liệu tại ngày lập. Vì vậy, kết nối tự động không đồng nghĩa mọi nơi phải đổi ngay sau mỗi lần sửa.

Nhận biết khi dữ liệu chưa đến

Khi hệ thống nguồn tạm thời không trả lời, bên nhận nên phân biệt “chưa lấy được dữ liệu” với “không có thông tin”. Hai trường hợp này có cách xử lý khác nhau; cùng hiển thị ô trống dễ khiến người xem kết luận sai.

Nếu giữ bản cũ để tiếp tục tra cứu, thời điểm của bản đó cần rõ. Khi kết nối hoạt động lại, quá trình nhận bản mới phải tránh tạo hồ sơ trùng và phải nhận biết những thay đổi đã được xử lý.

Để kiểm tra, hãy sửa một tài sản mẫu ở đúng nơi chịu trách nhiệm rồi mở các phần mềm còn lại. Xem mã và giá trị nhận được, thời gian cập nhật, tài khoản chỉ có quyền đọc và trường hợp nguồn không sẵn sàng. Tài liệu bàn giao nên ghi bên nào quản lý từng thông tin và liên hệ ai khi các nơi không khớp nhau. Đây là cơ sở để duy trì kết nối sau khi phần trình diễn đã kết thúc.

Nếu hồ sơ nguồn đã thay đổi nhưng bản đồ còn cũ, hãy kiểm tra thêm vai trò của tile, bộ nhớ đệm và bản dữ liệu đang hiển thị.

Một nguồn dữ liệu không gian dạng lớp cung cấp cùng nội dung cho bản đồ hiện trường, màn hình nghiệp vụ và báo cáo
Minh họa một nguồn dữ liệu được kết nối với nhiều nơi sử dụng trong hệ thống.