Integration error: Cannot access disposed object Follow
When running a socket integration or using a network location as your scan directory, you may encounter an error message like this within the logs:
ERROR|Integration [connection name] failed to send message. Details: 'Cannot access a disposed object.
Object name: 'System.Net.Sockets.Socket'.'
For FTP integrations, it may indicate that the FTP connection was temporarily refused. Increasing the polling time by a few seconds often relieves this issue.
For Socket integrations, a symptom of this error message may be completely skipping a label print. For very busy socket integrations, this error message likely will appear in the middle of a busy stream of socket requests or sometimes when the socket is idling.
In busy integrations, the socket doesn't always close when set to "Port Becomes Idle", so new requests are essentially smacking against an open door and pouring through without being processed.
To fix this, we need to control how and when BarTender opens and closes the socket. In the "Input Data" section of your integration, you can force the Integration to close the socket after it reads a certain sequence of characters.
The most straightforward means to do this is to search for the closing tag in the BTXML and force close the socket right afterwards. This method is shown in the steps for the Print Document Using BTXML over a Network Socket tutorial.
In the Input Data section of the Integration, change the settings as follows:
This tells the Integration to shut off the socket right after receiving </XMLScript>. The checkbox ensures that the closing tag is preserved within the input data so the BTXML script processes correctly.
In some cases, the socket may be cutting off the transmission too quickly so it appears that the Integration isn't receiving any data at all, so Version 1 essentially fails In this case, We'll need to add a custom tag into the BTXML to handle this situation.
In the BTXML script you're sending, add a tag into your script. For this example, we've added an <EOT/> tag into the BTXML:
The tag must be unique and not used anywhere else in the BTXML. If you are using SAP, it may not allow you to add the EOT tag outside the parent XMLScript tag, so you may have to add it inside the parent tag.
I've used EOT here as it's the standard abbreviation for End Of Transmission and is an uncommon sequence of characters.
Controlling the socket flow
In the "Input Data" section of the Integration, change the "Stop Reading When" setting to "Sequence of Characters is Received" and list the new tag in the Characters box without brackets:
The socket will shut off right after the T character and receive nothing after that. In this particular situation, the search sequence gets touchy about characters like < > and / so we can only search for the word itself. Make sure to check the checkbox to keep EOS in the BTXML for the next step
Correcting the BTXML
Because the socket cuts off right at the end of the character sequence, we'll need to add the missing BTXML back in so that BarTender can print it. Note: this may look different depending on the XML you're using. For this, we'll be adding in the missing tags as shown in the script at the start.
Add a Search and Replace action before the Print action:
In the action, change the source to %EventData% (or your custom variable that holds the integration data)
Next tell the Action what to search and replace:
Uncheck the boxes for "text contains variables" as we're using literal text.
After this, run a test to ensure that your BTXML travels through the socket normally. If you receive a BTXML error in your logs, ensure that you have the > after the XMLScript in the Search and Replace.