Hey Jainam.
I don't get a lot of hands on time with ASTM messaging but, from what you've shared, what you're receiving is using carriage returns.
The TCP Adapter does have a property of "Terminators" that is set to use ASCII Character 10 (line feed) for this, but this value is not configurable from the management portal (which is stated in the documentation)
I'm not sure if this is what you have tried where you stated "I've modified the class file", and I can't say for sure if this will work as I have no way to test it locally, but you could try creating a custom adapter which extends the in built adapter and overwrite the property, and then creating a custom service which extends the in built service and uses the custom adapter.
Something like:
Class Custom.EDI.ASTM.Adapter.TCPAdapter Extends EnsLib.EDI.ASTM.Adapter.TCPAdapter
{
/// Overwriting the original value of $C(10) (line feed) with $C(13) (carriage return)
Property Terminators As %String [ InitialExpression = {$C(13)} ];
}
and
Class Custom.EDI.ASTM.Service.TCPService Extends EnsLib.EDI.ASTM.Service.TCPService
{
Parameter ADAPTER = "Custom.EDI.ASTM.Adapter.TCPAdapter";
}
And finally, use the custom service in your production.
If this doesn't work, you might need to look into what your sending system is actually outputting for the carriage returns/line feeds.
Hey Joel.
Absolutely - there are a couple levels of ambiguity for the IDE without throwing a #dim in to know what that response object could be.
The biggest being that the target of the call of ..SendRequestSync/Async is something that can, and for good practice should, be configured within the Interoperability Production. Therefore the IDE has nothing to work from with regards to identifying what the response object will be to then provide code completion. Even if it's not configured within the Interoperability Production directly but a developer has simply declared the Target Dispatch Name as a string within the code, the link between that name and the target Class is still contained within the Production and could also not yet exist in the production at the time of development.
It's great to see the effort put into improving the Language Server which has massively reduced the need to use #dim, but I'm not we will see the last of it for some time.







I'm glad it worked!