Skip to main content

Posts

Showing posts from August, 2012

WCF MaxReceivedMessageSize max value in .config

MaxReceivedMessageSize parameter in binding config   file:   For max file size in WCF, we need to set following parameter in binding files. <binding name="MyService"        maxReceivedMessageSize="2147483647"        maxBufferSize="2147483647" transferMode="Streamed" >        <readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647"      maxArrayLength="2147483647" maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647"/> <!-- other binding info here, such as security --> </binding> Max possible size: MaxReceivedMessageSize to 2147483647 (i.e. Int32.MaxValue), which is 2GB For our case, as we are using WsHttpBinding. <wsHttpBinding>         <binding name="wsHttpBindingSettings" maxReceivedMessageSize="2147483647">           <readerQuotas maxDepth="2147483647" maxStringContentLength

WCF Config file setting

Metadata publishing Option: Service web.config file has option to publish metadata in <System.ServiceModel> tag < behaviors >       < serviceBehaviors >         < behavior name = " ServiceBehaviorConfiguration " >           < serviceDebug httpHelpPageEnabled = " true " httpsHelpPageEnabled = " false " includeExceptionDetailInFaults = " false " />           < serviceMetadata httpGetEnabled = " true " httpsGetEnabled = " false " />         </ behavior >       </ serviceBehaviors >     </ behaviors > User principal setting for WCF consumer client:   When we consume the WCF service, it will default add the current user credential as User Principal, but we can change that from App.Config file. After changing the User principal the service should respond as required. Default UserPricipal : < endpoint address = " http://localhost/BTS

Difference between Publishing orchestration as wcf service and schema as wcf service

Publishing an orchestration as a WCF Service leads to tight coupling . Whereas publishing schema as a WCF Service achieves loose coupling. When an orchestration is published as a WCF Service, the data (message) received via the WCF Service will be directly bound the Orchestration which is published. On the other hand when a schema is published as a WCF Service, the data (BizTalk message) received via the WCF Service will be published to the BizTalk Server Message Box and hence any number of subscribers can subscribe for the message. When we expose an orchestration as a WCF service, it means we should execute the orchestration by calling the WCF service from client with the parameter message payload same as what the orchestration receive shape expects. The message payload is received by message box first and the subscribing orchestration instance then gets fired and the 'processing' takes place very much similar to what happens inside the method of a WCF service which is

Convoy in BizTalk Orchestration

  Convoys are used when you receive related messages from diffirent sources or system and in dirrent order and on different time interval. Using convoys you can start the orchestration process and keep receiving the correlated messages either in parallel or sequentially. Thus there are two kind of convoys are possible. 1- Sequential - When you need to receive messages in predefined order then you need to use Sequential convoy. 2- Parallel - When you can receive the related messages in any order then you need to use parallel convoy.   How they are implemented in BizTalk : You achieve these convoy implementation in Biztalk using BizTalk orchestration. For sequential convoy you need to implement receive in a line and using correlation you need to correlate the next incoming message. For parallel convoy you need to use parallel shape and implement as many receive shapes as required. Again you will relate these messages using correlation.         Sequential Convoy In seque