Upon further investigation, we noticed "Event Type" in a event and in Background Task XML Settings, allows us to specify which service role can pick up the "publish" item. The service role is specified on the Background Task service running the batch server. So the question now becomes how can be manipulate "Event Type" of an event when we perform a publish of a publication. 

Hi Akheil,

I don't know if in today's world it is a good idea to distinguish between server1 or server2. That introduces a dependency that does not scale well, or which is a hotspot to not easily recover from when one of them fails. Furthermore it complicates your setup, it complicates any future upgrade. For that you need to share more why you are asking for this solution.

Still, it is possible. I would advise to check the various out-of-the-box PUBLISH events and how they are triggered in 

• \Websites\Author\EnterViaUI\Admin.XMLWriteObjPluginConfig.xml
• Websites\Author\EnterViaUI\Admin.XMLBackgroundTaskConfiguration.xml

So how the message arrives on the queue is often decided by an IWrite plugin that passes an EventType. In turn BackgroundTask handles the EventTypes as assigned to its Service Role. That Service Role is specified in the commandline of the registered service.

<plugin name="ISHRAISEPUBLISHEVENT" handler="RaisePublishEvent" ishcondition="ISHLevel='lng' and CurrentAction='SetMetadata'">
  <description>Starts a background task when the 'FISHPUBSTATUS' field is changed to 'Pending'</description>
  <workingset>
	<ishfields>
	  <ishfield name="FISHPUBSTATUS" level="lng"/>
	  <ishfield name="FISHEVENTID" level="lng"/>
	</ishfields>
  </workingset>
  <initialize>
	<parameters>
	  <parameter name="EventTypeConfiguration">
		<configuration>
		  <eventtype ishcondition="ISHOutputFormat.FDITAOTTRANSTYPE='ishditadelivery'">PUBLISHDITADELIVERY</eventtype>
		  <eventtype>PUBLISH</eventtype>
		</configuration>
	  </parameter>
	</parameters>
  </initialize>
</plugin>

Best wishes,
Dave

Hi David, 

We have three batch servers and perform post processing when a publication is released in Organize Space or Pub Manager. This custom release process, looks for the publication data/cache created when the publication was initially published and performs updates to the files which are then consumed by a downstream system we built internally. Having this post process creates a dependency that the cache/publication data needs to be synced between all batch severs, because if the publish was picked up by batch 1 and the release post process gets picked up by batch 2, it won't find the publication data folder and the process will fail. We discussed syncing the cache between batch servers, but that introduces latency and wait times for users to run the publish and post processes. Due to these reasons we are thinking of dividing the load between servers based on a metadata field, and this will ensure the publish and the post publish task will be picked up by the same batch server.

Hi David, 

We have three batch servers and perform post processing when a publication is released in Organize Space or Pub Manager. This custom release process, looks for the publication data/cache created when the publication was initially published and performs updates to the files which are then consumed by a downstream system we built internally. Having this post process creates a dependency that the cache/publication data needs to be synced between all batch severs, because if the publish was picked up by batch 1 and the release post process gets picked up by batch 2, it won't find the publication data folder and the process will fail. We discussed syncing the cache between batch servers, but that introduces latency and wait times for users to run the publish and post processes. Due to these reasons we are thinking of dividing the load between servers based on a metadata field, and this will ensure the publish and the post publish task will be picked up by the same batch server.

Thank you for the background Akheil... Be aware that you are introducing some kind of server-affinity that goes all the way to the user. It would not be my first choice, as there are ways to use a central caching system, or synchronization, or synchronization check (go copy from the other server just-in-time) without a user knowing. Giving the backend more control, when moving to different deployment structures (like more or less servers across dev-test-prod environments).