Một khách hàng có lịch tư vấn vào sáng thứ hai hằng tuần. Tuần này họ dời riêng cuộc hẹn sang chiều thứ ba. Nếu phần mềm nhận diện lần hẹn bằng giờ bắt đầu hiện tại, nó có thể giữ lịch sáng cũ và thêm lịch chiều mới. Trên màn hình xuất hiện hai cuộc hẹn, dù người dùng chỉ sửa một lần trong chuỗi.
Khi tích hợp Calendar API sự kiện lặp, vấn đề quan trọng là định danh một lần xuất hiện sau khi thời gian đã thay đổi. Bài này phân tích originalStartTime, recurringEventId và giờ đang hiển thị để đội xây website đặt lịch tránh gán sai hồ sơ. Ví dụ dùng dữ liệu giả định, không phải ảnh chụp lịch khách hàng.
Calendar API sự kiện lặp có nhiều lớp dữ liệu
Một chuỗi lịch và một lần xuất hiện trong chuỗi không phải cùng đối tượng. Chuỗi mô tả quy tắc lặp; một lần xuất hiện là cuộc hẹn cụ thể mà nhân viên cần phục vụ. Khi một lần được chỉnh riêng, nó trở thành ngoại lệ so với quy tắc. Phần mềm cần giữ được quan hệ này nếu muốn biết khách đang dời một buổi hay thay đổi cả lịch dài hạn.
Hướng dẫn recurring events của Google giải thích các lần xuất hiện và cách thay đổi riêng từng lần. Việc đọc về ngoại lệ có ý nghĩa ngay cả khi giao diện đặt lịch chỉ cho phép sửa một ngày. Nút đơn giản trên màn hình vẫn cần gửi đúng đối tượng để không ảnh hưởng những buổi còn lại.
Hãy tách ba câu hỏi trong mô hình dữ liệu: lần này thuộc chuỗi nào; nó vốn nằm ở vị trí nào của chuỗi; và hiện giờ diễn ra lúc nào. Nếu chỉ lưu câu trả lời cuối cùng, hệ thống rất khó giải thích một thay đổi sau khi khách dời lịch. Tên cuộc hẹn càng không đủ, vì nhiều tuần có thể dùng cùng tên.
originalStartTime giữ vị trí gốc của một lần hẹn
Theo tham chiếu tài nguyên Event, originalStartTime nhận diện lần xuất hiện trong chuỗi ngay cả khi nó đã được chuyển sang thời gian khác. recurringEventId liên kết nó với sự kiện lặp gốc. Trường start phản ánh thời gian bắt đầu hiện tại. Ba trường này trả lời những câu hỏi khác nhau, không nên thay thế lẫn nhau.
Ví dụ giả định: một lần vốn ở thứ hai lúc chín giờ, sau đó được chuyển sang thứ ba lúc mười bốn giờ. Vị trí gốc vẫn là lần thứ hai đó; giờ phục vụ hiện tại là chiều thứ ba. Mô hình nội bộ nên giữ cả hai, với định dạng và múi giờ được xử lý nhất quán. Không biến originalStartTime thành trường giờ hiển thị cho khách.
Một khóa nghiệp vụ cho vị trí lặp có thể kết hợp lịch, chuỗi và thời gian gốc đã chuẩn hóa. Đây là lựa chọn thiết kế cần kiểm thử, không phải một khóa tự phát sinh do cơ sở dữ liệu của doanh nghiệp được Google bảo đảm. Đồng thời vẫn giữ event ID do API trả về để thao tác đúng tài nguyên khi đọc hoặc sửa.
Ngày cả ngày cần cách xử lý riêng
Không ép mọi lịch thành một chuỗi ngày giờ theo múi giờ máy chủ. Sự kiện cả ngày và sự kiện có giờ có cách biểu diễn khác nhau. Một bộ chuyển đổi tự thêm nửa đêm rồi đổi múi giờ có thể làm ngày hiển thị lệch. Hãy lưu rõ loại giá trị, kiểm thử việc đọc lại và chỉ chuyển sang cách trình bày người dùng ở lớp giao diện.
Với đội làm việc nhiều múi giờ, nên giữ múi giờ đã dùng trong cấu hình chuỗi và ý nghĩa của dữ liệu nguồn. Không dùng giờ địa phương của máy chạy worker làm mặc định ngầm. Khi đối chiếu hai giá trị, cần biết chúng mô tả cùng một thời điểm hay cùng một ngày cả ngày; hai phép so sánh đó không giống nhau.
Một lịch tuần và một hồ sơ phục vụ
Giả sử một khóa học có chuỗi S3 và mỗi buổi có hồ sơ điểm danh riêng. Buổi thứ hai đầu tiên liên kết với hồ sơ B11; buổi tuần sau liên kết B12. Nếu chỉ dùng recurringEventId làm khóa duy nhất của hồ sơ, hai buổi sẽ ghi đè nhau. Nếu dùng giờ hiện tại, một buổi dời giờ lại có thể sinh thêm hồ sơ B13.
Giải pháp cần phản ánh đơn vị thực sự được doanh nghiệp phục vụ. Nếu điểm danh theo từng buổi, lưu liên kết tới lần xuất hiện cụ thể. Nếu hợp đồng áp dụng cho cả chuỗi, liên kết hợp đồng với chuỗi nhưng vẫn có các bản ghi buổi bên dưới. Không buộc mọi đối tượng nghiệp vụ cùng dùng một khóa vì API có sẵn một trường thuận tiện.
Khi nhận bản sửa của một ngoại lệ, worker đối chiếu định danh trước rồi cập nhật trường thuộc Calendar quản lý. Phiếu thu, ghi chú lớp học và quyết định của nhân viên giữ nguồn sở hữu riêng. Một thay đổi giờ trên lịch không tự động có nghĩa phải hoàn tiền, đổi người phụ trách hay gửi lại mọi thông báo đã phát trước đó.
Đọc các lần xuất hiện mà không trộn với chuỗi gốc
Phương thức events.instances dùng để lấy các lần xuất hiện của một sự kiện lặp. Ứng dụng cũng có lựa chọn mở rộng sự kiện khi liệt kê tùy cách truy vấn. Trước khi xây màn hình, quyết định rõ kho dữ liệu lưu quy tắc gốc, các lần mở rộng, hay cả hai trong những bảng có vai trò khác nhau.
Nếu cùng đưa chuỗi gốc và những lần mở rộng vào một danh sách cuộc hẹn mà không phân loại, tổng lịch có thể tăng sai. Ngược lại, nếu chỉ lưu chuỗi gốc rồi tự tính mọi lần trên màn hình, các ngoại lệ đã được người dùng sửa riêng có thể bị bỏ qua. Thiết kế cần một cách hợp nhất rõ ràng giữa quy tắc và ngoại lệ.
Cũng đừng suy rằng không thấy một lần trong một trang có nghĩa nó bị hủy. Có thể đang đọc sai khoảng thời gian, chưa đi hết trang hoặc thiếu quyền phù hợp. Chỉ dùng trạng thái và phạm vi đọc đã được xác minh để cập nhật hồ sơ. Phần đối soát không nên dùng tổng số dòng làm bằng chứng duy nhất về việc một buổi còn tồn tại.
Phân biệt sửa một lần và sửa từ một mốc trở đi
Giao diện cần làm rõ phạm vi trước khi nhân viên lưu thay đổi. Dời một buổi, thay cả chuỗi và thay từ một buổi trở đi là những yêu cầu khác nhau. Không đổi nhãn nút rồi gửi cùng một thao tác xuống API. Người dùng phải biết những buổi nào sẽ bị ảnh hưởng trước khi xác nhận.
Thay đổi từ một mốc về sau có thể cần xử lý lại cấu trúc chuỗi theo hướng dẫn chính thức. Vì vậy, liên kết nội bộ phải có đường đối chiếu khi chuỗi được tách. Đừng hứa rằng mọi định danh nghiệp vụ sẽ tự được giữ đúng nếu chưa thử các ngoại lệ đã tồn tại trước lần thay đổi đó.
Với ứng dụng chỉ cần đọc lịch, có thể để thao tác sửa diễn ra trên Calendar rồi đồng bộ kết quả về. Cách này giảm phạm vi chức năng phải hỗ trợ, nhưng vẫn cần xử lý ngoại lệ khi đọc. Với ứng dụng cho phép sửa ngay trên website, trách nhiệm giải thích phạm vi và kiểm thử hậu quả sẽ lớn hơn.
Bộ thử nhận diện đúng một buổi đã đổi giờ
Tạo một chuỗi thử nghiệm gồm vài buổi với tên giống nhau. Gắn mỗi buổi vào một mã hồ sơ giả. Sau đó dời một buổi sang ngày khác, sửa riêng tên một buổi khác và hủy một buổi. Kỳ vọng cần nêu theo từng hồ sơ, không chỉ ghi rằng API trả kết quả thành công.
Đọc lại các giá trị gốc và hiện tại sau mỗi thay đổi. Xác nhận buổi dời giờ vẫn đi vào hồ sơ cũ, buổi khác không bị ghi đè và buổi hủy không khiến cả chuỗi biến mất. Chạy lại lượt đọc để kiểm tra kết quả ổn định. Một tác vụ đọc lặp không nên tạo thêm phiếu điểm danh hoặc email xác nhận.
Thử thêm một sự kiện cả ngày và một trường hợp khác múi giờ trong môi trường có quyền sử dụng. Không cần đưa lịch khách thật vào kiểm thử. Báo cáo chỉ cần mã giả, loại thay đổi và kết quả đối chiếu; tên người tham gia, địa chỉ hay mô tả cuộc họp không giúp chứng minh tính đúng đắn của khóa nhận diện.
Trước khi nối luồng sửa lịch với website đang vận hành, nên thống nhất ranh giới thử nghiệm và dữ liệu production. Nếu cần Onter rà soát mô hình lịch lặp, liên kết hồ sơ và phạm vi sửa, hãy Nhận tư vấn & báo giá theo các tình huống thực tế. Giá liên hệ.
