EXCEPTION SEGMENT UNKNOWN RAISED error while calling RFC IDOCTYPE_READ_COMPLETE in Biztalk Middlewar

[rajeshps]

Hello Mates,

Good Day!

Currently we are facing issue when importing the extended idocs from SAP S4 to biztalk with IDOC segment release 701. We tried changing the WE20 outbound partner profiles parameter idoc release to 701 and also in T-code WE82 but no luck. All segments are in released stated and unlocked and also verified AUTH Issue.

I highly doubt the feasibility and compatability if SAP S4 actually accepts 701 release or not?!!!

Flow:

SAP S4 (idoc extension with 701 release)  -> MS Biztalk -> EDI Partners

Error:

Error while retrieving or generating the WSDL. Adapter message: Details: ErrorCode=RFC_EXCEPTION. ErrorGroup=RFC_ERROR_APPLICATION_EXCEPTION. SapErrorMessage=EXCEPTION SEGMENT_UNKNOWN RAISED.  AdapterErrorMessage=Error returned by RfcCallReceiveEx while calling RFC: IDOCTYPE_READ_COMPLETE..

Screenshot:

Thanks and Regards,

Rajesh PS

[rajeshps]

BIZTALK Middleware is Unable to view and import the iDoc lesser than 758 release but able to import the idoc successfully with 758 release.

[Ulrich_Schmidt1]

The fastest way to make progress here might be to just open IDOCTYPE_READ_COMPLETE in SE37, set an "external breakpoint" for the ABAP user used in BizTalk, and then start the call from BizTalk.

The exception SEGMENT_UNKNOWN could indeed mean what it says (e.g. BizTalk misspelling the segment name or using a wrong input), but I have also seen IDOCTYPE_READ_COMPLETE throwing this error, if the ABAP user had insufficient permissions.... 🙂  (But in that case I would assume, that every segment lookup would fail, not only those for IDocs of release < 7.58? Unless BizTalk uses a different user for these two kinds of IDocs?!)

So if there is only one ABAP user defined in BizTalk, then most probably BizTalk is doing something wrong, like using the E2 name instead of the E1 name, etc. That should then be visible in the ABAP debugger, when inspecting the inputs that BizTalk feeds into IDOCTYPE_READ_COMPLETE.

(The bug that IDOCTYPE_READ_COMPLETE throws SEGMENT_UNKNOWN when in fact the authorizations are missing, has been fixed a long time ago, and as you say, the backend is S/4, it most probably already has that fix. So I think the chances are quite high that BizTalk is doing something wrong here.)

But honestly: this BizTalk version looks very very old! It is still using the classic RFC library, which has been out-of-maintenance since 2016. (Support for Classic RFC Library Ends March 2016 SAP Blogs) I think Microsoft switched from classic RFC Lib to .NET Connector more than 10 years ago. Get the latest version, instead of wasting time with possible bugs that may have been fixed 10 years ago...!

PS: according to Microsoft, the BizTalk SAP Adapter was updated from classic RFC Lib to NCo with release "BizTalk 2013R2 Cumulative Update 2", which came 2015. So you are running a BizTalk version older than 2015. Considering how many bugs have been fixed in BizTalk since then, you may really be wasting your time here using these out-dated components.

[Ulrich_Schmidt1]

PS: another idea: as MS BizTalk will reach end-of-life in 2028 anyway, perhaps you can even use a different EDI tool for your IDoc processing needs?

I can recommend SAP Business Connector:

• It's included for free in any standard SAP license
• It has very similar functionality as BizTalk (e.g. in this case: receive IDocs from S/4, convert them into some other data format and then forward to some external receiver via HTTP, FTP, Email, JDBC, etc.)
• You get support for it by simply opening an SAP OSS ticket under component BC-MID-BUS

If you are still at the beginning of your project and not bound to BizTalk for some reason, you could give it a try.
Download is available at
​​https://support.sap.com/sbc-download
​Documentation:
​SAP Business Connector in Detail 

[rajeshps]

We cannot use any use new connector like SAP Business Connector. Idea is to reuse Biztalk mapping present with SAP ECC 6.0 to catch the time and faster route. So that is the reason of connecting SAP S4 Private Cloud with MS Biztalk 2016.

[rajeshps]

 Ulrich_Schmidt1

For now we wanted to solve this error and check if SAP S4 is actually feasible with 701 segment release and continue with Biztalk or not? I know its not a wise choose but considering other dimensions like time and faster solution in place for Interface delivery.

SAP S4 Privated Cloud 2023  ⇌ MS Biztalk 2016 ⇌ EDI Partners

 Am worried and concerned about the future state "what if this error is solved and live in production but after few weeks it rans into outdated function issues/ non supported functionality all of sudden either in Biztalk or SAP S4 that is  an extra Major later risk it can be inherent or residual too" .

https://community.sap.com/t5/technology-blog-posts-by-sap/support-for-classic-rfc-library-ends-march...

Below is the update from SAP 🙂 But am not convinced with SAP reply still " how biztalk works for 758 idoc extension but not with 701 idoc extension 😄

[rajeshps]

Error logs:Microsoft.Adapters.SAP.RFCException: Details: ErrorCode=RFC_EXCEPTION. ErrorGroup=RFC_ERROR_APPLICATION_EXCEPTION. SapErrorMessage=EXCEPTION SEGMENT_UNKNOWN RAISED. AdapterErrorMessage=Error returned by RfcCallReceiveEx while calling RFC: IDOCTYPE_READ_COMPLETE.. Server stack trace: at Microsoft.Adapters.SAP.RFCException.HelperThrow(Int32 retCode, String additionalErrorMessage) at Microsoft.Adapters.SAP.RfcOutboundInvoker.Invoke() at Microsoft.Adapters.SAP.InternalIdocMetadata..ctor(String idocType, String cimType, String release, String version, MetadataLookup metadataLookup, SAPConnection sapConnection, TimeoutHelper timeoutHelper) at Microsoft.Adapters.SAP.SAPMetadataContract.ResolveTypeMetadata(String typeId, TimeSpan timeout, TypeMetadataCollection& extraTypeMetadataResolved) at Microsoft.ServiceModel.Channels.Common.Design.MetadataCache.GetTypeMetadata(String uniqueId, Guid clientId, TimeSpan timeout) at Microsoft.ServiceModel.Channels.Common.MetadataLookup.GetTypeDefinition(String typeId, TimeSpan timeout) at Microsoft.Adapters.SAP.SapIdocMetadata..ctor(String absName, String idocType, String cimType, String release, String version, SAPConnection sapConnection, Boolean generateFlatFileCompatibleIdocSchema, Boolean segmentTypeInFlatFileAnnotation, MetadataLookup metadataLookup, TimeoutHelper timeoutHelper) at Microsoft.Adapters.SAP.SAPMetadataContract.ResolveTypeMetadata(String typeId, TimeSpan timeout, TypeMetadataCollection& extraTypeMetadataResolved) at Microsoft.ServiceModel.Channels.Common.Design.MetadataCache.GetTypeMetadata(String uniqueId, Guid clientId, TimeSpan timeout) at Microsoft.ServiceModel.Channels.Common.MetadataLookup.GetTypeDefinition(String typeId, TimeSpan timeout) at Microsoft.Adapters.SAP.IdocOperationMetadata.ExportXmlSchema(XmlSchemaExportContext schemaExportContext, MetadataLookup metadataLookup, TimeSpan timespan, OperationParameterDirection direction) at Microsoft.Adapters.SAP.IdocOperationMetadata.ExportInputXmlSchema(XmlSchemaExportContext schemaExportContext, MetadataLookup metadataLookup, TimeSpan timespan) at Microsoft.ServiceModel.Channels.Common.Design.WsdlBuilderHelper.AddOperationSchema(OperationMetadata operationMetadata, TimeSpan timeout) at Microsoft.ServiceModel.Channels.Common.Design.WsdlBuilder.SearchBrowseNodes(MetadataRetrievalNode[] nodes, WsdlBuilderHelper helper, TimeoutHelper timeoutHelper) at Microsoft.ServiceModel.Channels.Common.Design.WsdlBuilder.GenerateOperationSchemas(WsdlBuilderHelper helper, MetadataRetrievalNode[] nodes, TimeSpan timeout) at Microsoft.ServiceModel.Channels.Common.Design.WsdlBuilder.GetWsdl(MetadataRetrievalNode[] nodes, Uri uri, TimeSpan timeout) at Microsoft.Adapters.SAP.SapCustomWsdlRetrieval.GetWsdl(MetadataRetrievalNode[] nodes, Uri uri, TimeSpan timeout) at Microsoft.ServiceModel.Channels.Common.Design.MetadataExchanger.ProcessMetadataGet(Message message, Uri target, TimeSpan timeout, MetadataLookup metadataLookup) at Microsoft.ServiceModel.Channels.Common.Design.MetadataExchanger.ProcessMetadataMessage(Message message, Uri target, TimeSpan timeout, MetadataLookup metadataLookup, Message& replyMessage) at Microsoft.ServiceModel.Channels.Common.Channels.AdapterRequestChannel.Request(Message message, TimeSpan timeout) at System.ServiceModel.Dispatcher.RequestChannelBinder.Request(Message message, TimeSpan timeout) at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout) at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation) at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message) Exception rethrown at [0]: at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg) at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type) at Microsoft.ServiceModel.Channels.IMetadataRetrievalContract.GetMetadata(MetadataRetrievalNode[] nodes) at Microsoft.ServiceModel.Channels.Tools.MetadataSearchBrowse.MetadataPanel.GetWsdl(MetadataRetrievalNode[] nodes) at Microsoft.ServiceModel.Channels.Tools.MetadataSearchBrowse.MetadataUserControl.GetWsdl()