Wednesday, 8 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="2147483647"
            maxArrayLength="2147483647" maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647" />
        </binding>
</wsHttpBinding>
Please Note:
1.       But it’s recommended that the file size should be less, as the data is transferred through network there is possibility of slow network performance.

2.       We can set it to the maximum value, which is 2GB (2147483647) - or if we’re using streamed transfers we can go up to 263 bytes (almost 10,000,000 terabytes). But remember that by setting it to a value larger than necessary we may be opening our service (or client) to attacks.
3.       Only if the service is expected to receive messages larger than 65536 bytes. And in this case, we’d be increasing MaxReceivedMessageSize on the endpoints where we expect to receive such big messages.
4.       If the messages that our client/servers expect to receive are larger than the default value for MaxReceivedMessageSize, then we need to increase this quota.

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 :
                binding="wsHttpBinding" bindingConfiguration="WSHttpBinding_ITwoWayAsync1"
                contract="proxySchemaNameProcess.BTServiceExpose_NameProcess"
                name="WSHttpBinding_ITwoWayAsync1">
                 <identity>
                    <userPrincipalName value="mydefaultuser" />
                </identity>
            </endpoint>

Changed UserPricipal setting: used my current user
                binding="wsHttpBinding" bindingConfiguration="WSHttpBinding_ITwoWayAsync1"
                contract="proxySchemaNameProcess.BTServiceExpose_NameProcess"
                name="WSHttpBinding_ITwoWayAsync1">
                 <identity>
                    <userPrincipalName value="CurrentUser" />
                </identity>
            </endpoint>

Monday, 6 August 2012

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 decorated with [OperationContract] attribute.
·          
Now when a schema is exposed as a WCF service, it gives rise to a very loosely coupled pattern. Here only the schema is coupled, which is the contract of the 'contract first' approach. Here no 'processing' like orchestration is yet defined, which means, any orchestration can subscribe to the message payload received from the message box, when the WCF service is called by client. Here the loose coupling comes from the fact that we can simply make any, just any orchestration to subscribe to that message. Whereas, while you expose an orchestration as WCF service, you essentially mean to use that orchestration alone, a tighter coupling scenario.
Now the thing is after you expose certain schemas as WCF service, then when you add reference to the .svc file from your client application then appropriate proxy classes are created in the wsdl wherein all the types you declared are already available. This also happens when you consume the WCF service from another orchestration by saying "Add Generated Items --> Consume WCF service" eventually going through the WCF service consuming wizard. The types with appropriate namespaces would be automatically available to you and you need to populate the objects from your client code and call the service by submitting the payload

Thursday, 2 August 2012

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 sequential convoy all the types of messages are received in an ordered sequence. The first receive shape initializes the correlation set while the other receive shapes follow the correlation set. You can have the first receive shape’s activate property to true and set the initialize correlation property. While the other receive shapes will have the follow correlation set property set and activate property false.



Parallel Convoy

In the parallel convoy the messages arriving are not in a sequence and their sequence does not matter but the processing should be started when all the three messages are received. Configuring the parallel convoy is straight forward. Just drag the parallel shape and add the receive shapes in the parallel shape branches. If the parallel shape is the first shape in the orchestration then each parallel receive shape must have activate property to true and initialize the correlation set otherwise follow the correlation set initialized by any first receive shape or send shape.



Please refer below great article for more details.