I have a single server workflow application that now needs to be modified to support server to server replication (replication to local replicas isn’t a requirement). I have merge replication conflicts enabled for all the forms.
Here are my concerns:
Update Agent: This scheduled agent runs hourly on only one server. This agent takes information from Form A that has changed and updates corresponding fields in Form B. These fields include author/reader fields. The users can also update those author/reader fields by changing the workflow status of the Form B document (ie pressing “Approve”).
Thus a conflict will occur.
Audit log fields: This field gets timestamped with the person/time of each update. So this is another field that won’t surive the “merge conflicts” logic.
So I thought of maybe deferring the user’s workflow updates and only run them from the home server (same server that runs the update agents). This would also require me to defer the back end processing associated with a change in workflow status (email to next approver, logging “approval recap” fields, etc).
Does anyone have any ideas as to the best approach to handle situation?
thanks
barry
Subject: Ideas needed for replication strategy
The first question that springs to mind is; could users on serverX and users on serverY both change document1 inside the replication schedule window - either by changing it directly or changing another document that would need to change it?If so, this is not an application that is suitable for a multi-server replicated environment
If, however, the answer is no, then it may be possible
You’d have to move all of the hourly agent documentFormB processing logic to be on the save/close button of documentFormA - so the actual saving of documentFormA makes the changes
This would avoid the replication conflict - and if it also updated the audit info at the same time, then that woudln’t cause a conflict either
Chris
Subject: RE: Ideas needed for replication strategy
thanks for your response
<>
yes - the servers are located internationally and it’s possible (and even likely) that users on serverX and serverY could cause changes inside the replication window.
your suggestion is similar to my idea, only in reverse. I’m suggesting I defer the workflow updates (in this case serverY) while you’re saying to defer the scheduled updates (serverX)…
…how about instead of updating the serverX changes on save/close…I recognize the change in the postopen and update the changes then?
thanks
barry
Subject: RE: Ideas needed for replication strategy
"“how about instead of updating the serverX changes on save/close…I recognize the change in the postopen and update the changes then?”
You’d have the same problem, that you might now have conflicting changes
As I said in my opening paragraph, if the situtaion is as you ave described, then this app is not suitable for a multi-server replicated environment
SO, the ‘best’ solution is to make it single server, either via Notes client, as now, with attendant delays in response time, or possible a better way would be to make it a browser based app, with all users logging on to teh same server - you have already indicatee that ti works fine in a single server environment
Chris