c# - Best practice for ServiceBus message versioning -
i setting system transport messages between several internal services on servicebus topics. messages hold serialized objects. model objects defined quite complex trees of classes. means not practical maintain duplet versions of model structures in code.
we expect model structure change have exposed model version property on brokered message.
what best way handle transition when need upgrade model version?
i don't think need support 2 parallell model versions. concerned don't loose messages during transition. assume strategy upgrade sending services first , let subscribers continue process messages. when messages of previous version processed, time upgrade subscribing services.
what best mechanism skipping messages new version listening service not handling?
i know go old school , define parallell model versions using schemas json or xml, making possible listening service handle parallell versions. cumbersome, want avoid that.
i noticed brokeredmessage has defer method. useful? looked promising until realized messages "moved" live queue separate state need pulled referencing them key. not practical.
is possible postpone message modifying delivery time? couple of minutes fine. if same service still running time can postponed once again. (a working code example appreciated!)
do need create separate subscriptions based on model version? far allow different message types travel on same topic call redesign.
i have been looking @ similar yet implement can't provide full guidance, answer question on #3... have messages have flag re-queue message run again, e.g. process run every 5 minutes.
so during process extract object brokeredmessage:
var myobject = receivedmessage.getbody<mymodel>();
i complete message remove queue , create new brokeredmessage based on object , can set scheduledenqueuetimeutc field in future.
brokeredmessage brokeredmsg = new brokeredmessage(myobject); brokeredmsg.scheduledenqueuetimeutc = datetime.utcnow.addminutes(5); client.send(brokeredmsg);
so if want process 1 model version @ time, assign version number model , code in processor model number. if model higher, re-queue future time (until have updated code). if lower (a missed message), perhaps have exception handling.
Comments
Post a Comment