Thursday 26 February 2009
Wednesday 17 September 2008
Where will Custome functoid be feasible than Scripting functoid?
The Scripting functoid enables you to execute custom script in BizTalk map. For example, you can call a .NET assembly by using the Scripting functoid.
The change in the assembly does not require a redeployment of BizTalk server artifacts for the modification to be applied. Additionally, by encapsulating custom logic in an external assembly, any changes to that logic will require only that the external assembly is rebuilt and redeploy to the GAC. No changes to the BizTalk Server environment (aside from the BizTalk server restart to immediately apply the changes in the redeployed custom assembly) are required. Implementing this logic in the external assembly has the addition benefits allowing reuse of the logic, minimizing code maintenance and providing access to the debugging utilities with in visual studio.
The main benefit of using a custom functoid is that the assembly is hosted with in the BizTalk environment. The actual assembly file is located with in the Biztalk program file directory, and the functoid can be added to the Functoid toolbox with in the development environment. Using generic external assemblies is sometimes a requirement, however such as when existing logic contained within them needs to be accessed directly (with out modification to the source code or assembly location). This may be the case when using third party or proprietary assemblies, where you do not have access to the source code.
The change in the assembly does not require a redeployment of BizTalk server artifacts for the modification to be applied. Additionally, by encapsulating custom logic in an external assembly, any changes to that logic will require only that the external assembly is rebuilt and redeploy to the GAC. No changes to the BizTalk Server environment (aside from the BizTalk server restart to immediately apply the changes in the redeployed custom assembly) are required. Implementing this logic in the external assembly has the addition benefits allowing reuse of the logic, minimizing code maintenance and providing access to the debugging utilities with in visual studio.
The main benefit of using a custom functoid is that the assembly is hosted with in the BizTalk environment. The actual assembly file is located with in the Biztalk program file directory, and the functoid can be added to the Functoid toolbox with in the development environment. Using generic external assemblies is sometimes a requirement, however such as when existing logic contained within them needs to be accessed directly (with out modification to the source code or assembly location). This may be the case when using third party or proprietary assemblies, where you do not have access to the source code.
Thursday 28 August 2008
"IDOC_INBOUND_ASYNCHRONOUS" : WCF adapter
Error details: Microsoft.Adapters.SAP.RFCException: Details: ErrorCode=RFC_SYS_EXCEPTION. ErrorGroup=RFC_ERROR_SYSTEM_FAILURE. SapErrorMessage=IDoc adapter inbound: Sender port is initial. AdapterErrorMessage=Error occurred while calling function module "IDOC_INBOUND_ASYNCHRONOUS" in R/3..
Improper control records( Sender post or position ect..) could be the reason for specified error.
SapErrorMessage, This error message gives you some idea.
****************************************
Improper control records( Sender post or position ect..) could be the reason for specified error.
SapErrorMessage, This error message gives you some idea.
****************************************
An error occurred while adding data to buffer: WCF Adapter
Error Message:
"A message sent to adapter "WCF-Custom" on send port "TestWCFSAPSend" with URI "sap://CLIENT=nnn;LANG=EN;@a/sapxxxx/nn?RfcSdkTrace=True&AbapDebug=False&UseSapGui=Without" is suspended. Error details: Microsoft.ServiceModel.Channels.Common.XmlReaderParsingException: An error occurred while adding data to buffer."
Some of Causes:
1) Control record is not properly positioned
2) Document Number should be same at all places(Segments and control record) or 16(Length) spaces.
*****************************************************************************
"A message sent to adapter "WCF-Custom" on send port "TestWCFSAPSend" with URI "sap://CLIENT=nnn;LANG=EN;@a/sapxxxx/nn?RfcSdkTrace=True&AbapDebug=False&UseSapGui=Without" is suspended. Error details: Microsoft.ServiceModel.Channels.Common.XmlReaderParsingException: An error occurred while adding data to buffer."
Some of Causes:
1) Control record is not properly positioned
2) Document Number should be same at all places(Segments and control record) or 16(Length) spaces.
*****************************************************************************
Wednesday 13 August 2008
Some Information On WCF Adapter-SAP
The SAP.NET Connector exposes two classes for dealing with IDocs - SAPIDocSender, and SAPIDocReceiver (I hope I got the names correct). Both these methods deal only with data in "flat file" format as we call it - a bunch of lines of text - the first line represents the Control Record, and then each subsequent line represents a Segment.
The WCF Adapter exposes a Send() and Receive() method to do something almost similar. The difference is that the methods are actually something like Send(ORDERS05), Send(MATMAS03), etc (and similarly for Receive) - these operations are "strongly typed" to a specific IDoc, which allows for better validation. In order to obtain this metadata, at runtime, the adapter executes IDOCTYPE_READ_COMPLETE to get the metadata, so that the adapter can validate the data flowing across. Hence, we make the extra calls, for exposing extra functionality.
The Adapter also exposes a SendIdoc() and ReceiveIdoc() call, which is similar to the SAP.NET Connector - the functions just take in a String (which should contain the lines of text, with the first line being the control record, and subsequent lines being the data records) - in these functions, since there is no metadata to validate, the adapter won't make any extra calls to IDOCTYPE_READ_COMPLETE.
Therefore, you should be able to use the SendIdoc() / ReceiveIdoc() methods in your scenario.
This forum post seems to be very similar : http://forums.microsoft.com/msdn/ShowPost.aspx?PostID=3725298&SiteID=1, and also contains a MSDN link to the SendIdoc()/ReceiveIdoc() methods.
In the MSB UI, on the left pane, click on IDOC (which is the top level category along with RFC / TRFC / BAPI). In the right top pane, SendIdoc and ReceiveIdoc should show up - they appear there, since they are generic operations for all IDocs (as compared to Send/Receive, which only show up after you've navigated the tree to a particular MessageType+IdocType+Release+Version).
***************************************************
The WCF Adapter exposes a Send() and Receive() method to do something almost similar. The difference is that the methods are actually something like Send(ORDERS05), Send(MATMAS03), etc (and similarly for Receive) - these operations are "strongly typed" to a specific IDoc, which allows for better validation. In order to obtain this metadata, at runtime, the adapter executes IDOCTYPE_READ_COMPLETE to get the metadata, so that the adapter can validate the data flowing across. Hence, we make the extra calls, for exposing extra functionality.
The Adapter also exposes a SendIdoc() and ReceiveIdoc() call, which is similar to the SAP.NET Connector - the functions just take in a String (which should contain the lines of text, with the first line being the control record, and subsequent lines being the data records) - in these functions, since there is no metadata to validate, the adapter won't make any extra calls to IDOCTYPE_READ_COMPLETE.
Therefore, you should be able to use the SendIdoc() / ReceiveIdoc() methods in your scenario.
This forum post seems to be very similar : http://forums.microsoft.com/msdn/ShowPost.aspx?PostID=3725298&SiteID=1, and also contains a MSDN link to the SendIdoc()/ReceiveIdoc() methods.
In the MSB UI, on the left pane, click on IDOC (which is the top level category along with RFC / TRFC / BAPI). In the right top pane, SendIdoc and ReceiveIdoc should show up - they appear there, since they are generic operations for all IDocs (as compared to Send/Receive, which only show up after you've navigated the tree to a particular MessageType+IdocType+Release+Version).
***************************************************
Receiving Idocs - getting the raw idoc data
How to skip the calling of the SAP RFC function modules in WCF adapter
Question:
Dear All,
Does anyone know if it is possible to disable the calling of the following SAP RFC function module call "IDOC_INBOUND_ASYNCHRONOUS"/ "IDOCTYPE_READ_COMPLETE", which the WCF LOB SAP adapter seems to be making.
We are trying to post an IDOC type into an SAP system, however the particular IDOC type does not exist in the said SAP system.
It seems with the WCF LOB SAP adapter there are additional RFC calls made to perform checks in SAP, which prevents the posting of IDOCs if they do not exist. In the old SAP .Net Connector, there were no such checks and you could post any IDOC into an SAP system, if it exists in the system or not.
Here, I am trying to post IDOC to SAP PI system which does not contain all type messages.
Any suggestion welcome.
Thanks in Advance,
Answers:
1)
We cannot avoid calling IDOC_INBOUND_ASYNCHRONOUS since that is the way to send an IDoc to SAP. However if you want to avoid calling IDOCTYPE_READ_COMPLETE you can use the generic SendIDoc function in the SAP adapter. This RFC is called to get the metadata of the IDoc. You can get more details regarding this in the related blog
http://blogs.msdn.com/adapters/archive/2007/12/14/receiving-idocs-from-sap-using-the-sapbinding-requires-higher-sap-user-privilege-as-compared-to-the-older-mysap-adapter-really.aspx
2)
Related question here: http://forums.microsoft.com/msdn/ShowPost.aspx?PostID=3725298&SiteID=1
-Sheshu
Dear All,
Does anyone know if it is possible to disable the calling of the following SAP RFC function module call "IDOC_INBOUND_ASYNCHRONOUS"/ "IDOCTYPE_READ_COMPLETE", which the WCF LOB SAP adapter seems to be making.
We are trying to post an IDOC type into an SAP system, however the particular IDOC type does not exist in the said SAP system.
It seems with the WCF LOB SAP adapter there are additional RFC calls made to perform checks in SAP, which prevents the posting of IDOCs if they do not exist. In the old SAP .Net Connector, there were no such checks and you could post any IDOC into an SAP system, if it exists in the system or not.
Here, I am trying to post IDOC to SAP PI system which does not contain all type messages.
Any suggestion welcome.
Thanks in Advance,
Answers:
1)
We cannot avoid calling IDOC_INBOUND_ASYNCHRONOUS since that is the way to send an IDoc to SAP. However if you want to avoid calling IDOCTYPE_READ_COMPLETE you can use the generic SendIDoc function in the SAP adapter. This RFC is called to get the metadata of the IDoc. You can get more details regarding this in the related blog
http://blogs.msdn.com/adapters/archive/2007/12/14/receiving-idocs-from-sap-using-the-sapbinding-requires-higher-sap-user-privilege-as-compared-to-the-older-mysap-adapter-really.aspx
2)
Related question here: http://forums.microsoft.com/msdn/ShowPost.aspx?PostID=3725298&SiteID=1
-Sheshu
Subscribe to:
Posts (Atom)
