Welcome to MSDN Blogs Sign in | Join | Help

Could not load file or assembly 'Microsoft.SqlServer.Diagnostics.STrace, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91' or one of its dependencies. The system cannot find the file specified.

Another error on executing SQL Server 2008 Management Studio and just trying to connect to Database Engine. Though after pressing OK on the error mentioned, everything works but Management Node won’t work and you would keep on getting this error again and again.

 

Apart from this if you are trying to configure Microsoft BizTalk Server 2009 – BizTalk EDI/AS2 Runtime it would also fail with the same error, rest all the BizTalk components would function.

 

To resolve this, follow the steps below:

1. Run Command Prompt and find the location of the DLL using

    > dir Microsoft.SqlServer.Diagnostics.STrace.dll /s

2. Copy the location with the DLL name.

3. Run VS 2008 Command Prompt as Administrator.

4. Execute the following

    GACUTIL –i “{Location of Microsoft.SqlServer.Diagnostics.STrace.dll} found at step 1”

 

And both the situations would get resolved.

Posted by ashishme | 0 Comments

Fixing BizTalk ENTSSO Failure on Windows 7, Vista or Server 2008 after VS 2010 Beta Installation

I've been running BizTalk 2009 on my Windows 7 machine, and after installing VS 2010 beta 2, the Enterprise Single Sign-On Service stopped working.

It failed with the following error:

Could not create SSOSQL. To fix the problem, reinstall SSO or try 'regasm SSOSQL.dll' from a Visual Studio command prompt.
Error Code: 0x80131700

The file is located at C:\Program Files\Common Files\Enterprise Single Sign-On\SSOSQL.dll

Run Visual Studio Commmand prompt as Administrator and run 'regasm "C:\Program Files\Common Files\Enterprise Single Sign-On\SSOSQL.dll"'.

Posted by ashishme | 0 Comments

Microsoft BizTalk Server and Microsoft Dynamics AX Integration - Configuring Message Properties in BizTalk Server for sending data to Microsoft Dynamics AX

The configuration that needs to be performed on BizTalk Server Message properties in order to send data to Microsoft Dynamics AX using BizTalk Dynamics AX Adapter and Application Integration Framework (AIF) is as follows:

To send data to Microsoft Dynamics AX from BizTalk there are properties that needs to be set on the message, before Microsoft Dynamics AX adapter can push the same.

The following properties need to be set on the message:

i. Set the Dynamics Action on the Message as per the Action configured in Microsoft Dynamics AX:

_message (Dynamics.Action)

ii. Set the Dynamics Destination Endpoint on the Message as per the Destination Endpoint configured in Microsoft Dynamics AX:

_message (Dynamics.DestinationEndpoint)

iii. // Set the Dynamics Source Endpoint on the Message as per the Destination Endpoint configured in Microsoft Dynamics AX

_message (Dynamics.SourceEndpoint)

iv. // Set the Dynamics Source Endpoint User on the Message as per the Destination Endpoint configured in Microsoft Dynamics AX

_message (Dynamics.SourceEndpointUser)

Here is the sample for the setting the properties for VendTable:

// Set the Dynamics Action for VendTable

msg_VendTableRequest(Dynamics.Action)="createListVendTable"; // this too can be made configurable and taken from SSO

// Set the Dynamics Destination Endpoint from the SSO Config

msg_VendTableRequest(Dynamics.DestinationEndpoint) =  SSOConfigHelper.Read("BizTalk.OracleFinancials.VendorData", "Dynamics.DestinationEndpoint");

// Set the Dynamics Source Endpoint from the SSO Config

msg_VendTableRequest(Dynamics.SourceEndpoint) = SSOConfigHelper.Read("BizTalk.OracleFinancials.VendorData", "Dynamics.SourceEndpoint");

// Set the Dynamics Source Endpoint User from the SSO Config

msg_VendTableRequest(Dynamics.SourceEndpointUser) = SSOConfigHelper.Read("BizTalk.OracleFinancials.VendorData", "Dynamics.SourceEndpointUser");

Posted by ashishme | 0 Comments

Microsoft BizTalk Server and Microsoft Dynamics AX Integration - Part 4.2 - Error Identification at Dynamics AX

Dynamics AX Queue Manager

The Queue Manager is internal queue maintained in Microsoft Dynamics AX. This Queue is the bridge between Dynamics AX and external systems.

All the messages sent from other systems or needs to be sent to external systems from Microsoft Dynamics AX goes through the Queue. The Queue Manager UI lets you monitor the messages sent to / from Dynamics AX.

The messages that for which exception occur would not be moved out of the Queue Manager and can be tracked using the UI.

Steps to monitor data under Queue Manager:

1. Under Basic module, click on “Periodic” -> “Application Integration Framework” -> “Queue Manager

image

 

Document History

The Document History maintains the history of all the messages sent to / from the Microsoft Dynamics AX. It’s a kind of Log of messages.

Steps to view data under Document History:

1. Under Basic module, click on “Periodic” -> “Application Integration Framework” -> “Document History

image

 

Exceptions

The exception view provides the details of Exceptions that occurred while processing messages received by Microsoft Dynamics AX. This view only provides the details of exceptions raised by Microsoft Dynamics AX.

1. Under Basic module, click on “Periodic” -> “Application Integration Framework” -> “Exceptions

image

2. To view the details of the Exception, right click and select Record Info, then select Show All Fields. This would display the details of the Exception as below:

image

 

Repost Messages

Microsoft Dynamics AX would be sending data to Microsoft BizTalk Server using Application Integration Framework (AIF). In case the any exception occurs while transmitting the data through AIF, the exception gets logged in the exception list as mentioned above.

Microsoft Dynamics AX would be configured to auto send the new / updated data to BizTalk Server. This would be done by configuring and executing Batch in Dynamics AX. For details related to this contact the Full Scope Team.

In case of errors, the administrators can repost the data using the Microsoft Dynamics AX UI. The batch still needs to run which actually post the data into the Dynamics AX Queue from where the BizTalk Adapter would pick the data and send the same to the Message Box.

The steps below detail the how to post an Invoice data manually, this posting of Invoices can be done in case there has been an exception in the batch process which posting invoices:

1. Click on the “Accounts Payable” module in Microsoft Dynamics AX

image

 

2. Click on “Purchase Orders

image

 

3. Click on “Posting” -> “Invoice” and press “OK”.

image

Posted by ashishme | 0 Comments

Windows Communication Foundation (WCF) - Transport, Message Security and Mutual Authentication using Certificates

At a high level the steps required to use self signed certificates for Transport & Message Security for securing the messages sent between a client and service, and also how to use certificates to perform Mutual Authentication between client and service layer are as follow:

1. Create Self signed certificates for Client and Server.

2. Export Client Certificate for Installation on Client machine.

3. Export Server Certificate for Installation on Server machine.

4. Install the Client Certificate on the Client machines.

5. Add the Client Certificate to the Trusted Root Certification Authorities on the client machines.

6. Install the Server Certificate on the Server machine.

7. Add the Server Certificate to the Trusted Root Certification Authorities on the Server machine.

8. Export the Server’s Public key of the Server Certificate.

9. Establish Trust for the Server’s Public key on the Client Machine.

10. Export the Client’s Public key of the Client Certificate.

11. Establish Trust for the Client’s Public key on the Server Machine.

12. Enable Transport Layer security on the Web Site in Microsoft Internet Information Server (IIS).

13. Service Layer configuration for enabling the certificates for Mutual Authentication, Transport & Message level security.

14. Client side configuration for enabling the certificates for Mutual Authentication, Transport & Message level security.

 

Detailed procedure to be followed for configuring certificate based Mutual Authentication, Transport and Message Security between Client and WCF based services:

1. Create Self signed certificates for Client and Server:

To establish the identity of the Server and Clients, we require 2 certificates. First certificate will represent the identity of the Server, where as the second certificate will be used to represent all the clients that can connect to the Server (Once the Mutual Authentication is successful).

There are different utilities available for generating Self Signed Certificates viz.:

a. MakeCert utility

(Refer http://msdn.microsoft.com/en-us/library/bfsktky3(VS.80).aspx for more details)

b. Use Microsoft Internet Information Server (Refer the steps below)

c. Use Certificate Server

 

The following steps are required to be followed in order to create Self Signed certificates using Microsoft Internet Information Server (IIS):

a. Run Microsoft Internet Information Server

image

 

 

b. Click on the Server Name (e.g. ASHISH-ME) as shown in the above figure.

image

 

c. Click on Server Certificates

image

 

d. Click on “Create Self-Signed Certificate”, which will open a Certificate Generation Wizard. Provide a Friendly Name for the Certificate and click “OK”, as shown below:

image

 

e. The new certificate would get created and added to the list of Server Certificates, as shown below:

image

 

f. Repeat steps (d) and (e) to create a certificate that would be used by clients to prove their identity to the server. As shown in the figure below a new certificate with Friendly Name as “ClientCertificate” is added to the list of available certificates.

image

 

2. Export Client Certificate for Installation on Client machine:

The Client Certificate needs to be exported with the Private Key and installed on the Client Machine from which the Services would be called. To achieve the same the following steps are required to be followed:

a. Select the Client Certificate, right Click and select “Export”

image

 

b. In the Export Dialog, enter the path where the Certificate would get generated; make sure that the .pfx extension is selected as even Private Key of the certificate needs to be exported. Enter the Password to protect the certificate as it contains the Private Key.

image

 

3. Export Server Certificate for Installation on Server machine:

   Follow the same steps as mentioned for the export of the Client Certificate.

 

4. Install the Client Certificate on the Client machines:

The Client Certificate needs to be installed and configured on the client machine. The below steps describes the procedure for the same.

a. Go to Start -> Run and execute MMC.exe.

image

 

b. On the MMC select File menu and select Add/Remove Snap In.

image

 

c. Select “Certificates” and click “Add” button.

image

 

d. Select “Computer Account” on the “Certificates snap-in” dialog box.

image

 

The above selection should be based upon the usage of the certificate and for who the certificate is being installed is intended for. Follow the guidance below for selecting the certificate store:

1. Select “My user account” if the certificate needs to be associated with the logged in user. If chosen so, only the logged in user would be able to get access to the installed certificate. This certificate would not be available to any other user who can Log-in to the same computer.

2. Select “Service Account” if the certificate needs to be associated with the Service Account. The applications running under the Service Account would only be able to access the certificate.

3. Select “Computer Account” if the certificate needs to be associated with the Computer. The certificates installed here can be accessed by any user / Service Account who can Login to the Computer.

 

e. Select “Local Computer” in the “Select Computer” dialog.

image

 

f. Press “OK” on the “Add or Remove Snap-in” dialog.

image

 

g. On the MMC console, select the Certificates (Local Computer) -> Personal -> Certificates

image

 

h. Right Click on Certificates, select “All Tasks -> Import

image

 

i. Follow the “Import Certificate Wizard” and select the path where ClientCertificate.pfx was exported or is copied.

image

 

j. Since the certificate was “Password Protected”, the wizard would prompt you to enter the password.

Note: Select “Mark this key as exportable” only if the private key needs to be marked as exportable.

image

 

k. Select “Place all the certificates in the following store”, and make sure that the certificate store is selected as “Personal”

image

 

l. Complete the “Certificate Import Wizard” the certificate would appear under the “Certificates” in Personal store.

 

5. Add the Client Certificate to the Trusted Root Certification Authorities on the client machines:

As this being a Self Signed Certificate the Certificate Issuer needs to be added to the list of Trusted Root Certification Authorities.

a. On the MMC console, select the Certificates (Local Computer) -> Trusted Root Certification Authorities -> Certificates

b. Right Click on Certificates, select “All Tasks -> Import

image

 

c. Follow the “Import Certificate Wizard” and select the path where ClientCertificate.pfx was exported or is copied.

image

 

d. Since the certificate was “Password Protected”, the wizard would prompt you to enter the password.

Note: Select “Mark this key as exportable” only if the private key needs to be marked as exportable.

image

 

e. Select “Place all the certificates in the following store”, and make sure that the certificate store is selected as “Trusted Root Certification Authorities”

image

 

 

f. Complete the “Certificate Import Wizard” the certificate would appear under the “Certificates” in Trusted Root Certification Authorities store.

 

6. Install the Server Certificate on the Server machine:

Follow the procedure mentioned in step 4 on the Server Machine to install the certificate on the Server. The “ServerCertificate.pfx” needs to be selected.

 

7. Add the Server Certificate to the Trusted Root Certification Authorities on the Server machine:

Follow the procedure mentioned in step 5 on the Server Machine to add the Server Certificate to Trusted Root Certification Authorities. The “ServerCertificate.pfx” needs to be selected.

 

8. Export the Server’s Public key of the ServerCertificate using the MMC.exe on the Server machine:

The Server’s Public Key needs to be exported, for establishing a Trust for the Server’s certificate on the Client’s machines.

a. Run MMC.exe on the Server’s machine and add Certificates snap-in for the Computer Account. (The steps for the same have already been described under step 4 (a - f)).

b. Select the “ServerCertificate” under “Certificates (Local Computer) -> Personal -> Certificates

c. Right click and select “Export

image

 

d. On the Certificate Export Wizard select “No, do not export the private key

image

 

e. On the Certificate Export Wizard select the file format for exported certificate as “Base-64 encoded X.509 (.CER)

image

 

f. Provide the path where the file with Certificate Public key would be generated.

image

 

9. Establish Trust for the Server’s Public key on the Client Machine:

The Client needs to Trust the Server’s certificate based upon the ServerCertificate public key, the below step details the procedure for the same:

a. Execute the MMC.exe on the Client Machine and add Certificates snap-in for the Computer Account. (The steps for the same have already been described under step 4 (a - f)).

b. Select “Certificates (Local Computer) -> Trusted People -> Certificates

c. Right click and select “Import

image

 

d. In the Certificate Import Wizard provide the path of the Server’s certificate (ServerCertificate.cer) that was exported as part of the step 8 and only has the Public Key.

image

 

e. Select “Place all the certificates in the following store”, and make sure that the certificate store is selected as “Trusted People

image

 

f. Complete the “Certificate Import Wizard” the certificate would appear under the “Certificates” in Trusted People store.

 

10. Export the Client’s Public key of the ClientCertificate using the MMC.exe on any of the Client machine:

Follow the procedure described in step 8 on any one of the Client Machine to for establishing a Trust for the Client’s certificate on the Server machine.

 

11. Establish Trust for the Client’s Public key on the Server Machine:

Follow the procedure described in step 9 on the Server Machine for importing the Client’s Public Key under Trusted People Store of the Server machine. The “ClientCertificate.cer” generated as part of step 10 needs to be selected.

 

12. Enable Transport Layer security on the WebSite in Microsoft Internet Information Server (IIS)

To enable and use the certificate created for Transport Layer security the following steps needs to be performed on IIS:

a. Start Microsoft Internet Information Server (IIS).

b. Select the Web Site on which the Transport Layer Security needs to be enabled.

c. Right Click and select “Edit Bindings”

image

 

d. Under Site Bindings dialog box select the protocol type “https” and press Edit

image

 

e. Under Edit Site Binding, for “SSL Certificate” select the certificate created for Server “serverCertificate” as shown in the figure below:

image

 

 

13. Service Layer configuration for enabling the certificates for Mutual Authentication, Transport & Message level security.

 

Assumptions:

a. The wsHttpBinding is being used for the exposing the endpoint to enable the client to connect and call the WCF Services.

b. Security mode to be used “TransportWithMessageCredential

 

The following configuration needs to be performed on WCF Service config file:

1. Customize the Binding (in this example wsHttpBinding)

  • Set the Security Mode for wsHttpBinding as “TransportWithMessageCredential
<configuration>
    <system.serviceModel>
       <bindings>
         <wsHttpBinding>
            <binding name="wsHttp">
               <security mode="TransportWithMessageCredential"/>
            </binding>
         </wsHttpBinding>
       </bindings>
    </system.serviceModel>
</configuration>
  • Set the clientCredentialType as “Certificate” for both Transport and Message level security
<configuration>
    <system.serviceModel>
       <bindings>
         <wsHttpBinding>
            <binding name="wsHttp">
               <security mode="TransportWithMessageCredential">
                  <transport clientCredentialType="Certificate"/>
                  <message clientCredentialType="Certificate" negotiateServiceCredential="true" />
               </security>
            </binding>
         </wsHttpBinding>
       </bindings>
    </system.serviceModel>
</configuration>

2. Customize the Service Behavior

  • Set the serviceCertificate details under serviceCredentials

i. Set storeName to “My

ii. Set storeLocation to “LocalMachine

iii. Set x509FindType to “FindByThumbprint

iv. Set findValue to the value of Thumbprint for ServerCertificate installed. Steps to find the Thumbprint for Server Certificate are as follows:

    1. Run MMC.exe on the Server and add Certificates snap in to manage certificates under “Computer Account” (refer steps 4a to 4f) for details on adding the Certificates snap in)

    2. Traverse to “Certificates (Local Computer) -> Personal -> Certificates”

    3. Select the Certificate with Friendly name as “ServerCertificate”, as shown in the figure below:

    image

    4. Right Click on the selected certificate and select Open

    5. Traverse to the “Details” Tab on the Certificate Details dialog.

    image 

     6. Select and Copy the value of the Field “Thumbprint” as shown in the figure below:

     image

     7. Set the value of the findValue in the configuration file for serviceCredentials -> serviceCertificate as the selected Thumbprint value.

v. The below is the extract from the configuration file with the serviceCredentials -> serviceCertificate values set.

<configuration>
   <system.serviceModel>
      <behaviors>
	 <serviceBehaviors>
	    <behavior name="serviceBehavior">
               <serviceCredentials>
                  <serviceCertificate findValue ="92 b0 e3 24 42 38 bb a1 e0 29 77 20 3e 29 36 15 63 33 dd 64" 
                     x509FindType="FindByThumbprint" storeLocation="LocalMachine" storeName="My"/>
               </serviceCredentials>
	    </behavior>
 	 </serviceBehaviors>
      </behaviors>
   </system.serviceModel>
</configuration>
  • Set the clienteCertificate -> certificate details under serviceCredentials

i. Set storeName to “TrustedPeople

ii. Set storeLocation to “LocalMachine

iii. Set x509FindType to “FindByThumbprint

iv. Set findValue to the value of Thumbprint for ClientCertificate trusted. Steps to find the Thumbprint for Server Certificate are as follows:

     1. Run MMC.exe on the Server and add Certificates snap in to manage certificates under “Computer Account” (refer steps 4a to 4f) for details on adding the Certificates snap in)

     2. Traverse to “Certificates (Local Computer) -> Trusted People -> Certificates”

     3. Select the Certificate with Issued By as the name of the Server where Client Certificate was generated , as shown in the figure below:

image

    4. Right Click on the selected certificate and select Open

    5. Traverse to the “Details” Tab on the Certificate Details dialog.

image

     6. Select and Copy the value of the Field “Thumbprint” as shown in the figure below:

image

     7. Set the value of the findValue in the configuration file for serviceCredentials -> clientCertificate -> certificate as the selected Thumbprint value.

v. Set the certificateValidationMode as PeerTrust for serviceCredentials -> clientCertificate -> authentication.

vi. The below is the extract from the configuration file with the serviceCredentials -> clientCertificate and authentication values set.

<configuration>
   <system.serviceModel>
      <behaviors>
	 <serviceBehaviors>
	    <behavior name="serviceBehavior">
               <serviceCredentials>
                  <serviceCertificate findValue ="92 b0 e3 24 42 38 bb a1 e0 29 77 20 3e 29 36 15 63 33 dd 64" 
                     x509FindType="FindByThumbprint" storeLocation="LocalMachine" storeName="My"/>
                  <clientCertificate>
                     <certificate findValue="c5 c0 12 2a a8 64 02 21 ca 4b 41 87 68 14 7b a3 6e d3 92 ff" 
                        x509FindType="FindByThumbprint" storeLocation="LocalMachine" storeName="TrustedPeople"/>
                     <authentication certificateValidationMode ="PeerTrust"/>
                  </clientCertificate>
               </serviceCredentials>
	    </behavior>
 	 </serviceBehaviors>
      </behaviors>
   </system.serviceModel>
</configuration>

3. Associate the Custom Binding created above with the Service Endpoint and Service Behavior created above with the Service.

<configuration>
   <system.serviceModel>
      <services>
	 <service name="HelloIndigo.HelloIndigoService" behaviorConfiguration="serviceBehavior">
            <endpoint address="" binding="wsHttpBinding" contract="HelloIndigo.IHelloIndigoService" bindingConfiguration="wsHttp"/>
	 </service> 
      </services>
      <behaviors>
	 <serviceBehaviors>
	    <behavior name="serviceBehavior">
               <serviceCredentials>
                  <serviceCertificate findValue ="92 b0 e3 24 42 38 bb a1 e0 29 77 20 3e 29 36 15 63 33 dd 64" 
                     x509FindType="FindByThumbprint" storeLocation="LocalMachine" storeName="My"/>
                  <clientCertificate>
                     <certificate findValue="c5 c0 12 2a a8 64 02 21 ca 4b 41 87 68 14 7b a3 6e d3 92 ff" 
                        x509FindType="FindByThumbprint" storeLocation="LocalMachine" storeName="TrustedPeople"/>
                     <authentication certificateValidationMode ="PeerTrust"/>
                  </clientCertificate>
               </serviceCredentials>
	    </behavior>
 	 </serviceBehaviors>
      </behaviors>
      <bindings>
         <wsHttpBinding>
            <binding name="wsHttp">
               <security mode="TransportWithMessageCredential">
                  <transport clientCredentialType="Certificate"/>
                  <message clientCredentialType="Certificate" negotiateServiceCredential="true" />
               </security>
            </binding>
         </wsHttpBinding>
      </bindings>
   </system.serviceModel>
</configuration>

 

14. Client side configuration for enabling the certificates for Mutual Authentication, Transport & Message level security.

The following configuration needs to be performed on Client’s config file:

1. Update Service References on the Client project.

2. Customize the Binding (in this example wsHttpBinding)

  • Set the Security Mode for wsHttpBinding as “TransportWithMessageCredential
<configuration>
   <system.serviceModel>
      <bindings>
         <wsHttpBinding>
            <binding name="WSHttpBinding_IHelloIndigoService" closeTimeout="00:01:00"
                openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"
                bypassProxyOnLocal="false" transactionFlow="false" hostNameComparisonMode="StrongWildcard"
                maxBufferPoolSize="524288" maxReceivedMessageSize="65536"
                messageEncoding="Text" textEncoding="utf-8" useDefaultWebProxy="true">
               <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384"
                   maxBytesPerRead="4096" maxNameTableCharCount="16384" />
               <reliableSession ordered="true" inactivityTimeout="00:10:00" />
               <security mode="TransportWithMessageCredential">
               </security>
            </binding>
         </wsHttpBinding>
      </bindings>
   </system.serviceModel>
</configuration>
  • Set the clientCredentialType as “Certificate” for both Transport and Message level security 
<configuration>
   <system.serviceModel>
      <bindings>
         <wsHttpBinding>
            <binding name="WSHttpBinding_IHelloIndigoService" closeTimeout="00:01:00"
                openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"
                bypassProxyOnLocal="false" transactionFlow="false" hostNameComparisonMode="StrongWildcard"
                maxBufferPoolSize="524288" maxReceivedMessageSize="65536"
                messageEncoding="Text" textEncoding="utf-8" useDefaultWebProxy="true">
               <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384"
                   maxBytesPerRead="4096" maxNameTableCharCount="16384" />
               <reliableSession ordered="true" inactivityTimeout="00:10:00" />
               <security mode="TransportWithMessageCredential">
                  <message clientCredentialType="Certificate" negotiateServiceCredential="true" />
		  <transport clientCredentialType="Certificate"/>
               </security>
            </binding>
         </wsHttpBinding>
      </bindings>
   </system.serviceModel>
</configuration>

3. Customize the Service Behavior

  • Set the clientCertificate details under clientCredentials

i. Set storeName to “My

ii. Set storeLocation to “LocalMachine

iii. Set x509FindType to “FindByThumbprint

iv. Set findValue to the value of Thumbprint for ClientCertificate installed. Steps to find the Thumbprint for Server Certificate are as follows:

    1. Run MMC.exe on the Server and add Certificates snap in to manage certificates under “Computer Account” (refer steps 4a to 4f) for details on adding the Certificates snap in)

    2. Traverse to “Certificates (Local Computer) -> Personal -> Certificates”

    3. Select the Certificate with Friendly name as “ClientCertificate”, as shown in the figure below:

    image

    4. Right Click on the selected certificate and select Open

    5. Traverse to the “Details” Tab on the Certificate Details dialog.

    image

    6. Select and Copy the value of the Field “Thumbprint” as shown in the figure below:

    image

    7. Set the value of the findValue in the configuration file for clientCredentials -> clientCertificate as the selected Thumbprint value.

v. The below is the extract from the configuration file with the clientCredentials -> clientCertificate values set.

<configuration>
   <system.serviceModel>
        <behaviors>
          <endpointBehaviors>
             <behavior name="wsHttpEndpointBehavior">
                <clientCredentials>
                   <clientCertificate findValue="c5 c0 12 2a a8 64 02 21 ca 4b 41 87 68 14 7b a3 6e d3 92 ff" 
                     x509FindType="FindByThumbprint" storeLocation="LocalMachine" storeName="My"/>
                </clientCredentials>
             </behavior>
          </endpointBehaviors>
        </behaviors>
   </system.serviceModel>
</configuration>
  • Set the serviceCertificate -> authentication details under clientCredentials

i. Set certificateValidationMode to “PeerTrust

<configuration>
   <system.serviceModel>
        <behaviors>
          <endpointBehaviors>
             <behavior name="wsHttpEndpointBehavior">
                <clientCredentials>
                   <clientCertificate findValue="c5 c0 12 2a a8 64 02 21 ca 4b 41 87 68 14 7b a3 6e d3 92 ff" 
                     x509FindType="FindByThumbprint" storeLocation="LocalMachine" storeName="My"/>
                   <serviceCertificate>
                      <authentication certificateValidationMode="PeerTrust" />
                   </serviceCertificate>
                </clientCredentials>
             </behavior>
          </endpointBehaviors>
        </behaviors>
   </system.serviceModel>
</configuration>

4. Associate the Custom Binding created above with the Service Endpoint and Service Behavior created above with the Service.

<configuration>
   <system.serviceModel>
      <client>
         <endpoint address="https://serverUrl" binding="wsHttpBinding"
             bindingConfiguration="WSHttpBinding_IHelloIndigoService"
             contract="WinClient.localhost.IHelloIndigoService" 
             name="WSHttpBinding_IHelloIndigoService" behaviorConfiguration="wsHttpEndpointBehavior">
         </endpoint>               
      </client>
      <bindings>
         <wsHttpBinding>
            <binding name="WSHttpBinding_IHelloIndigoService" closeTimeout="00:01:00"
                openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"
                bypassProxyOnLocal="false" transactionFlow="false" hostNameComparisonMode="StrongWildcard"
                maxBufferPoolSize="524288" maxReceivedMessageSize="65536"
                messageEncoding="Text" textEncoding="utf-8" useDefaultWebProxy="true">
               <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384"
                   maxBytesPerRead="4096" maxNameTableCharCount="16384" />
               <reliableSession ordered="true" inactivityTimeout="00:10:00" />
               <security mode="TransportWithMessageCredential">
                  <message clientCredentialType="Certificate" negotiateServiceCredential="true" />
		  <transport clientCredentialType="Certificate"/>
               </security>
            </binding>
         </wsHttpBinding>
      </bindings>
      <behaviors>
        <endpointBehaviors>
           <behavior name="wsHttpEndpointBehavior">
              <clientCredentials>
                 <clientCertificate findValue="c5 c0 12 2a a8 64 02 21 ca 4b 41 87 68 14 7b a3 6e d3 92 ff" 
                   x509FindType="FindByThumbprint" storeLocation="LocalMachine" storeName="My"/>
                 <serviceCertificate>
                    <authentication certificateValidationMode="PeerTrust"/>
                 </serviceCertificate>
              </clientCredentials>
           </behavior>
        </endpointBehaviors>
      </behaviors>
   </system.serviceModel>
</configuration>
Posted by ashishme | 1 Comments

WCF Champ Web Campaign

clip_image001

The schedule:

1. April 2nd, 2009 9:00 PM EST - http://www.youtube.com/watch?v=ZXQtZsC0JZ4

2. April 9th, 6:00 A.M. PST, 9:00 AM EST

3. April 16th, 6:00 A.M. PST, 9”00 AM EST

The WCF Champ Website: Gateway to resources that jumpstart developers’ learning curve regarding WCF.

Posted by ashishme | 1 Comments

Microsoft BizTalk Server and Microsoft Dynamics AX Integration - Part 4.1 - Error Handling with BizTalk Administration

Categories of Exceptions related to BizTalk / Dynamics AX Interfaces

1. When error Event Source: “Microsoft Dynamics AX adapter

a. Refer the Microsoft Dynamics AX Server Event Log for more details

b. Refer the Microsoft Dynamics AX Exceptions

2. When error Event Source: “Microsoft BizTalk Server” / “EAI.BizTalk

a. This category of error is related to some error in Transformation, Orchestration or Transport.

b. Refer the BizTalk Administration Console for more details.

 

Microsoft BizTalk Server

(Event Source: “Microsoft BizTalk Server” / “EAI.BizTalk”)

This section provides the information on the exceptions that gets logged by BizTalk in case of erroneous conditions for Microsoft Dynamics AX interfaces.

All the Exceptions that occur in Microsoft BizTalk Server are logged in Event Log of the BizTalk Server machine. These exceptions are logged on the Machine based upon the Host Instance configuration.

Apart from the Error / Detailed exception the Message / Orchestration also gets “SUSPENDED as either Resume-able or Non-Resume able state based upon the category and nature of the Exception.

The following sections detail the steps to be followed in case the error Event Source is “Microsoft BizTalk Server” / “EAI.BizTalk”.

1. Error Handling for data being sent to Microsoft Dynamics AX from BizTalk Server

1. Error occurs in the Interface which sends data to Microsoft Dynamics AX.

a. Case I: If the error occurs while transforming the data received from the Source Systems into Canonical Message.

i. In this case the message would get suspended.

ii. The suspended messages can be retrieved using Microsoft BizTalk Server Administration Console.

image

iii. If the message needs to be replayed without any correction and is resume-able, then right-click click on the Suspended Message and click on “Resume Instance”.

iv. If the message needs to be corrected, then the data needs to be altered in Source System and reposted to BizTalk.

b. Case 2: If the error occurs after the data has been transformed into the Canonical

i. The Interface would output / dump the Canonical Message to a configured location as per the Send Error Port.

image

ii. After correcting the issue in the Canonical Message the file can be replayed using the configured Error Replay folder (check under “EnterpriseShared” BizTalk Application)

image

iii. Rename the Canonical as “ForInterfacePopulateVendorInfoToDynamicsAX.xml”  and drop the File at above configured location (“C:\Project\ErrorReplay” folder). Microsoft BizTalk Server would route the corrected canonical to the right Interface and perform the required transformations.

2. Error Handling for data being received from Microsoft Dynamics AX into BizTalk Server

1. Error occurs in the Interface which receives data from Microsoft Dynamics AX.

a. Case I: If the error occurs while transforming the data received from the Microsoft Dynamics AX.

i. In this case the message would get suspended.

ii. The suspended messages can be retrieved using Microsoft BizTalk Server Administration Console.

image

iii. If the message needs to be replayed without any correction and is resume-able, then right-click click on the Suspended Message, and click “Resume Instance”.

iv. If the message needs to be corrected, then the data needs to be altered in Microsoft Dynamics AX and reposted (refer Section - Repost Messages)

b. Case 2: If the error occurs after the data received from the Microsoft Dynamics AX has been transformed into the Canonical (for Interface with Orchestration).

i. The Interface would output / dump the Canonical Message to a configured location as per the Send Error Port.

For example an interface which sends Invoice Information to Oracle. In case of BizTalk Error the Canonical XML or the message is outputted to “C:\Project\Error\IPublishInvoiceOnError\%MessageID%.xml

image

 

ii. After correcting the issue in the Canonical Message the file can be replayed using the configured Error Replay folder (check under “EnterpriseShared” BizTalk Application)

image

iii. Rename the Canonical as “ForInterfacePublishInvoice.xml”  and drop the File at above configured location (“C:\Project\ErrorReplay” folder). Microsoft BizTalk Server would route the corrected canonical to the right Interface and perform the required transformations.

b. Case 3: If the error occurs after the data received from the Microsoft Dynamics AX has been transformed into the Canonical (for Interface without Orchestration).

i. In this case the message would get suspended.

ii. The suspended messages can be retrieved using Microsoft BizTalk Server Administration Console.

image

iii. If the message needs to be replayed without any correction and is resume-able, then right-click click on the Suspended Message, and click on “Resume Instance”.

iv. If the message needs to be corrected then double click on any Suspended Message

image

v. Go to “Messages” tab.

image

vi. Double Click on the Message.

image

vii. Click on Body and copy the Message and store it on the Hard disk.

viii. Correct the message and rename the file as per the Interface (refer the Design Document for the corresponding Interface for the same)

ix. Drop the file at above configured location (“C:\Project\ErrorReplay” folder). Microsoft BizTalk Server would route the corrected canonical to the right Interface and perform the required transformations.

This explains what all can be done on BizTalk side in case there are issues related to the Dynamics AX port connection. In my next port I will describe how we can do the error handling on Dynamics AX – the message was successfully sent to Dynamics AX queue but failed to perform the required action.

Posted by ashishme | 1 Comments

Microsoft BizTalk Server and Microsoft Dynamics AX Integration - Part 3 - Receive Data from Dynamics AX in BizTalk

Microsoft Dynamics AX adapter pulls the data available in the Dynamics AX Queue and publishes it into the Message Box. In one BizTalk Group there can be only one Receive Location that points to a combination of AOS Server Name and AOS Port Number. This is valid for the Receive Locations across BizTalk Applications.

The following configuration needs to be performed in BizTalk Receive Port / Receive Location which would receive the data from Microsoft Dynamics AX using the Application Integration Framework (AIF) and publish the same into BizTalk Message Box:

1. A Static One Way port needs to be created under Receive Port in BizTalk Application

image

2. The following provides the configuration for Receive Location –

a. Select the Transport Type as “Microsoft Dynamics AX”, also choose the Receive handler and Receive pipeline as per the requirements of the Interface.

image

b. Press “Configure” and set the following properties:

i. Set “Authentication Type” = “Host User

ii. Set “Gateway User” as BizTalk user under which the BizTalk Host Instance is executing.

iii. Set “AOS Server” to the name of “Dynamics AX Server

iv. Set “AOS Port” to the port number on which of Dynamics AX Server is running – the default is 2712.

image

Posted by ashishme | 0 Comments

Microsoft BizTalk Server and Microsoft Dynamics AX Integration - Part 2 - Send Data from BizTalk to Dynamics AX

The following configuration needs to be performed in BizTalk Send Port which would send the data from the BizTalk Server to the Microsoft Dynamics AX using the Application Integration Framework (AIF):

1. Create a New Send Port or use an existing Send Port (in case Orchestration is used).

2. Select the Transport Type as “Microsoft Dynamics AX”, and provide the details like Send Handler, Send pipeline and Receive pipeline as per the requirements of the Interface.

 

image

 

3. Press “Configure” and set the following properties:

a. Set “Authentication Type” = “Host User

b. Set “Gateway User” as BizTalk user under which the BizTalk Host Instance is executing.

c. Set “AOS Server” to the name of “Dynamics AX Server

d. Set “AOS Port” to the port number on which of Dynamics AX Server is running – the default is 2712.

image

 

Configuring Message Properties for sending data to Microsoft Dynamics AX

To send data to Microsoft Dynamics AX from BizTalk there are properties that needs to be set on the message, before Microsoft Dynamics AX adapter can push the same.

The following properties need to be set on the message:

i. Set the Dynamics Action on the Message as per the Action configured in Microsoft Dynamics AX:

_message (Dynamics.Action)

ii. Set the Dynamics Destination Endpoint on the Message as per the Destination Endpoint configured in Microsoft Dynamics AX:

_message (Dynamics.DestinationEndpoint)

iii. Set the Dynamics Source Endpoint on the Message as per the Destination Endpoint configured in Microsoft Dynamics AX

_message (Dynamics.SourceEndpoint)

iv. Set the Dynamics Source Endpoint User on the Message as per the Destination Endpoint configured in Microsoft Dynamics AX

_message (Dynamics.SourceEndpointUser)

 

Here is the sample for the setting the properties:

// Set the Dynamics Action for VendTable

msg_VendTableRequest(Dynamics.Action)="createListVendTable"; // this too can be made configurable and taken from SSO

// Set the Dynamics Destination Endpoint from the SSO Config

msg_VendTableRequest(Dynamics.DestinationEndpoint) =  SSOConfigHelper.Read("BizTalk.OracleFinancials.VendorData", "Dynamics.DestinationEndpoint");

// Set the Dynamics Source Endpoint from the SSO Config

msg_VendTableRequest(Dynamics.SourceEndpoint) = SSOConfigHelper.Read("BizTalk.OracleFinancials.VendorData", "Dynamics.SourceEndpoint");

// Set the Dynamics Source Endpoint User from the SSO Config

msg_VendTableRequest(Dynamics.SourceEndpointUser) = SSOConfigHelper.Read("BizTalk.OracleFinancials.VendorData", "Dynamics.SourceEndpointUser");

Posted by ashishme | 1 Comments

Remote Debugging basics

Here is the article that explains the basics for remote debugging in details: “Remote debugging with Visual Studio 2008”

The summary from the same article:

Getting the remote debugger to work

To get the remote debugger up and running, you must install it on the remote computer (ie, the server in the previously described scenario) and then configure it. Configuration is complex because the remote debugger authenticates both ways; that is, the machine running Visual Studio needs to authenticate on the remote machine, and the remote machine needs to authenticate on the machine running Visual Studio.

Installation

When you install Visual Studio 2008, remote debugging components install by default. In addition, the remote debugger is readily available on the Visual Studio installation media. The installation disc contains a directory called Remote Debugger, which has two folders (x64 and x86) that contain the set-up application for the specific platform. This installs the remote debugging monitor (msvsmon.exe). In my example, it is installed on a server.

Once the installation application runs, the configuration wizard runs. The configuration wizard allows you to set up the remote debugger to run as a service or as an application. Running the remote debugger as a service means that it will run all the time, so you may want to run it as an application so it can be run only when needed. At this point, security becomes an important aspect of set-up.

Security

The remote debugger must run using a user account that has the appropriate privileges. It must use an account that has at least the same privileges as the account used to run the application being debugged.

When working with ASP.NET applications, the ASP.NET worker process (aspnet_wp.exe) usually runs with an account called ASPNET, so you must use this account (or an account with equal or greater privileges) to remotely debug it. A safe bet is running the remote debugger with administrative level access, but this is not advisable for a production environment since the remote debugger needs to communicate with your debugger via the network, thus putting the server at risk of being hacked. I like to create a specific account for the remote debugger with a name like VSDebugger and make sure it has appropriate access.

Using the remote debugger

Once you install all the components, you can use the remote debugger with your own applications. Follow these steps to use it with a C#/VB.NET application:

|> In Visual Studio, choose Properties on the Project menu.
|> Select Debug from the Properties page.
|> For the Start Action setting, select Start External Program and in the field type the complete path to the executable on the host computer (running the remote debugger monitor).
|> Under Start Options in the working directory box, type the directory where the executable is located.
|> Select Use Remote Machine and type the name of the remote computer in the field. You can specify any command line arguments to pass to the application on the remote computer.
|> Start the Remote Debugging Monitor on the remote computer.
|> In Visual Studio, you can begin debugging the application via the usual Debug menu by selecting Start to begin a debugging session.

When working with an ASP.NET application, be sure to reference the remote computer by name and not the IP address. Also, the application's web.config file must have the debug attribute set to True. The site's security settings must allow windows authentication (or anonymous), and make sure there are no firewall restrictions that may disable remote debugging. MSDN offers more information about setting up remote debugging.

Go to the source

Visual Studio 2008's remote debugger feature allows you to investigate code issues where they occur. You may use Visual Studio on your development machine and connect to the problem code on a remote host; this allows you to find problems specific to the host environment. During set-up, it's important to use the proper accounts with necessary access. Add the remote debugger to your developer toolbox for those situations where problems are unique to an application's environment.

Posted by ashishme | 0 Comments

32 bit vs 64 bit

Check out the the article: “How 64-bit version of Windows differs architecturally from 32-bit version”

The summary from the article:

Sometimes understanding the underlying architecture of a system is critical to being able to work with that system safely and effectively. The x64 version of Windows is a perfect example of this.

Windows XP and Windows Server 2003 are both available in 64-bit versions which are designed to run on x64 hardware. These x64 Windows operating systems run 64-bit code natively but can also run 32-bit code through the use of an integrated emulator called Windows on Windows 64 (WOW64).

No big deal, you say. After all, the 32-bit versions of the various Windows operating systems are designed to run both 32-bit and 16-bit code simultaneously. (Technically, it's not truly running simultaneously, but explaining how the multitasking engine handles 16-bit code is for another tip).

The point is that 32-bit versions of Windows have a complicated mechanism in place to allow 32- and 16-bit code to run side by side. Still, the system is designed so that whether you're a systems administrator or a casual user, you don't need to know how these mechanisms work.

But 64-bit versions of Windows are different. From a user's standpoint, 64-bit applications simply run side by side with 32-bit applications; nothing special is going on. But for administrators (and members of the help desk), it's a different story: The 32-bit code must be kept isolated from 64-bit code. This isolation is so important that x64 versions of Windows have two registries, one for 64-bit code and one for 32-bit code.

Even though the 64-bit versions of Windows XP and Windows Server 2003 look and act almost identical to their 32-bit counterparts, below the surface there are major differences. If you perform certain tweaks on a 64-bit version of Windows in the same way you did in the 32-bit version, you could cause some problems.

DLL hell
The first rule of 64-bit applications is this: You absolutely cannot mix 32- and 64-bit code in a single application. If you have a 64-bit application, everything related to that application, including the DLL files, must be 64-bit. This presents an interesting challenge because sometimes multiple applications will rely on a common DLL file. Fortunately, Windows keeps 32-bit DLL files separate from 64-bit DLL files.

If you look in the \Windows folder on any 32-bit system, you'll see two subdirectories: one named SYSTEM and one named SYSTEM32. The SYSTEM subdirectory is a leftover from Windows 3.x that has remained in Windows for the purpose of maintaining backward compatibility with older applications. Generally speaking, 16-bit DLL files (and other support files) are placed in the \Windows\System folder; 32-bit DLLs and various support files are placed in the \Windows\System32 folder.

The way that 32-bit versions of Windows maintain the separation between 16- and 32-bit DLLs is fairly straightforward. The way that 64-bit versions of Windows keep 64-bit and 32-bit DLL files separate is not.

Logically, Microsoft should have created a folder named \Windows\System64 and used it for 64-bit DLL files. Instead, Microsoft created a new folder named SysWOW64 for storing the 32-bit DLLs. At first glace, this makes sense when you consider that WOW64 is the name of the emulator that runs 32-bit applications. But keep in mind that 32-bit applications are designed to place their DLL files in the \Windows\System32 folder.

The \Windows\System32 folder still exists in the x64 version of Windows. But Microsoft uses this folder as a repository for 64-bit DLLs, not 32-bit DLLs. I don't understand Microsoft's reasoning for using the \Windows\System32 folder for 64-bit DLLs, but I've heard it has to do with backward compatibility.

So what about all those 32-bit applications that are designed to store their DLL files in the \Windows\System32 folder? This is where things get confusing.

As I mentioned earlier, 32-bit code can not run natively through the X64 version of Windows. In order to run 32-bit applications, Windows makes use of the WOW64 emulator, which makes the apps think they are running on a 32-bit version of Windows.

When you install a 32-bit application, that installation wizard is running within the WOW64 emulator. Remember: 32-bit and 64-bit code don't mix. Once an application (including a Setup wizard) launches from within the WOW64 emulator, it must continue to run within WOW64. This means that when you install an application, the Setup wizard has no idea that the app is being installed on a 64-bit version of Windows, and will write DLL files to the \Windows\System32 folder just as if it were running in a 32-bit operating system.

Of course, WOW64 knows that the Setup wizard is a 32-bit application running within an emulator. It also knows that 64- and 32-bit code cannot be mixed. As such, the WOW64 emulator aliases an alias to the \Windows\SysWOW64 folder. This means that any time a 32-bit application needs to read or write anything to or from the \Windows\System32 folder, the WOW64 emulator transparently redirects the request to the \Windows\SysWOW64 folder.

All of this means that if you were to manually manipulate the contents of the \Windows\System32 folder, you could be in for some nasty surprises. I recently read about an administrator who needed to install a couple of small support scripts for an existing application. The instructions that came with the scripts said they should be placed in the \Windows\System32 folder. Of course those instructions assumed that the application would be running on a 32-bit system.

The scripts didn't cause the system to crash. Instead Windows gave the illusion that the update had never been applied. When the admin ran the application, it was transparently being redirected to the \Windows\SysWOW64 folder. The admin knew he had placed the scripts into the \Windows\System32 folder and could see the scripts from Windows Explorer, but could not figure out why the application could not see the scripts. Thinking the issue was permissions-related, he spent a lot of time chasing his tail. Had he known about the way the x64 versions of Windows keep DLLs separated, he could have just placed the scripts into the \Windows\SysWOW64 folder. They would have worked as anticipated.

The x64 versions of Windows represent one of the few cases in which it is truly important for an admin to understand the underlying system architecture. My next article iwill discuss differences in the ways that Windows maintains 64- and 32-bit program files.

Posted by ashishme | 0 Comments

Microsoft BizTalk Server and Microsoft Dynamics AX Integration - Part 1 - Configuring Microsoft Dynamics AX – Application Integration Framework (AIF) for Integration with BizTalk

This is the first part of the four part series where I would be sharing what all needs to be configured in Dynamics AX and BizTalk Server in order for both to be integrated and send / receive messages from each other.

In first part I am starting with explaining the configuration that needs to be performed on Microsoft Dynamics AX – AIF (for integration with BizTalk)

In order to integrate BizTalk with Microsoft Dynamics AX we need to configure the Application Integration Framework which acts as a bridge between the two. The following steps lists down the steps to set up the Application Integration Framework which exposes data to BizTalk Microsoft Dynamics AX adapter.

 

1.     Start the Microsoft Dynamics AX client, and browse to the Basic Module

image001

2.     Create the Local Endpoint or make sure that the Local Endpoint is configured:

A local endpoint is the origination for sent messages and the destination for received messages. There may be more than one local endpoint, depending on how many companies are configured for your Microsoft Dynamics AX installation.

 

a.     Click Basic à Setup à Application Integration Framework à Local endpoints.

b.    Press CTRL+N to create a new local endpoint record.

c.     Select a company from the Company field.

d.    Enter a name for the endpoint in the Local endpoint field.

e.     The name for the local endpoint should be representative of the Microsoft Dynamics AX company name that participates in the exchange.

f.     Press CTRL+S to save the data.

image002 


 

3.     Configure an adapter

The following adapters are available after installing Microsoft Dynamics AX:

a.     AifFileSystemAdapter

b.    AifMSMQAdapter

c.     AifWebServiceAdapter

d.    AifBizTalkAdapter

 

To configure an adapter for use in a channel, you activate it and specify its direction (inbound, outbound, or both) on the Transport adapters form. Ensure that Transport Adapter is configured for AifBizTalkAdapter.

a.     Click Basic à Setup à Application Integration Framework à Transport Adapters.

b.    Press CTRL+N to create a new transport adapter record.

c.     Select the AifBizTalkAdapter from the list of Adapter classes available.

image003 

d.    Enter a Name and make it active by selecting the “Active” checkbox (that is shown in the above figure as “A”), so that it is available for use.

e.     The default value for AifBizTalkAdapter is “Receive and Respond” and this cannot be changed (as AifBizTalkAdapter is used for both sending and receiving data between BizTalk and Microsoft Dynamics AX).

image004

 

 

4.     Creating and configuring channels

Channels define the transport method that enables messages to move in and out of the framework to reach the endpoint. Before configuring a channel, a transport adapter must be available.

Channels may support inbound transfers only, outbound only, or both. Configuration settings are different depending on the direction for the transfer in the channel as well as for different adapters. Inbound channels may use a response channel that handles verification or error responses to inbound transfers.

a.     Click Basic à Setup à Application Integration Framework à Channels.

b.    Press CTRL+N to create a new channel.

c.     Select an adapter in the Adapter field.

You must first have activated an adapter on the Transport adapters form before it appears in the list of available adapters.

d.    Enter the unique identification information for the new channel, including an identifier in the Channel ID field and a friendly name in the Name field.

a.     Provide the channel ID as “BizTalkChannel

b.    Provide the friendly Name as “BizTalkChannel

e.     To activate the channel and allow it to participate in document exchanges, click Active (or “A” as shown in the figure).

f.     Configure the address for the adapter.

a.     Provide the address as “BizTalkChannel

g.    Select from the available directions for the transfers to be performed in this channel The list of available directions depends on the adapter.

a.     Provide the direction as “Both

image005

h.     If the direction is set to Inbound / Both, you can select a response channel.

Inbound channels can use an outbound channel called a "response channel" to transfer or "respond back" to the source endpoint with verification results or error responses to inbound transfers.

i.      On the General tab, set the Maximum batch size to the maximum number of messages to be processed at one time from the queues. You can select Unlimited if you do not want to limit this number.

j.      Press CTRL + S to save the created / configured channel.

image006

 

k.     Now select the Channel created and press “Configure”, and enter the list of BizTalk Server groups as shown below:

image007

image008

 

l.      Enter the names of the computers running BizTalk Server that belong to the specified BizTalk group. Press CTRL+N to add each server to the list.

m.   Press CTRL+S to save the channel.

 

5.     Configure an action:

An action refers to the document and the operation to be performed on it, such as Send or Receive.

a.     Click Basic à Setup à Application Integration Framework à Action.

b.    To register all actions for document classes that exist, click Scan and register.

image009

c.     After all items are scanned and registered, select “Enabled” (in above figure the checkboxes with Column named as “E…”) to enable the actions you need for your exchange.

Enable the action corresponding to the Interface, for example: “createListVendTable” for Interface 32.


 

6.     Creating and configuring endpoints

Using Application Integration Framework (AIF), you enable document exchanges between endpoints and the local endpoint. A local endpoint is the origination for sent messages and the destination for received messages. That is, the local endpoint refers to your Microsoft Dynamics AX installation.

An endpoint is the destination for an outbound document and the source of an incoming document. That is, an endpoint represents your trading partner in a document exchange.

Before you can configure an endpoint, the following must already exist and be configured:

a.     A local endpoint.

b.    A named action for the exchange, consisting of a document and a description of the operation to be performed on it.

c.     Microsoft Dynamics AX users to be associated with the endpoint.

d.    An outbound channel must be already be defined if needed.

 

Steps to configure / create endpoint:

a.     Click Basic à Setup à Application Integration Frameworkà Endpoints.

b.    Press CTRL+N to create a new endpoint, or select an existing endpoint from the list to be modified.

c.     Enter a unique Endpoint ID and user friendly name.

image010

                                                          i.    Enter Endpoint ID as “Inbound Vendors”. (an example)

                                                         ii.    Enter friendly name as “Inbound Vendors”. (an example)

d.    Go to “Constraints” tab and select “No Constraints” checkbox (as shown in figure below

image011

 

e.     Go back to the “Overview” tab, and select / provide the “Local endpoint ID” from the list of local endpoint configured. (for example “Company Name” as shown in figure below)

image012

 

f.     Now click on the “General” tab and select the “Outbound channel ID” from the list of Channels already configured (for example “BizTalkChannel” as shown below)

image013

 

e.     Configure Action Policies:

To enable exchange of documents for endpoints, select which actions an endpoint may perform. This process is called configuring endpoint action policies.

a.     To Configure the Action Policies for the End Point and associate action and endpoint, click on the “Action Policies

i.    Press CTRL + N  to create a new Endpoint Action policy and select from the List of Actions displayed

image014

ii.    Set the Status as “Enabled” and Logging Mode as “Log All

image015

 

f.     Configure Action Data Policies:

A document is made up of many data fields. When you set up a document exchange, you decide, on a field-by-field basis, which data fields are transferred. This is known as the data policy. You configure the data policy on the Data Policies form.

a.     To Configure the Action Data Policies for each of the Action Policies configured above.

i.    Select the Action Id in the window shown in figure above and click on Data Policies.

ii.    Enable the fields as per the schema / requirements of the Interface

iii.    Mark the fields as required which are not Optional as part of the Interface requirements / schemas.

image016 

 

g.    Configure an endpoint user

You must enter information for at least one endpoint user or trusted intermediary who is authorized to initiate transactions for the endpoint on the Users tab.

Follow the steps mentioned below:

a.     Click the Users tab.

b.    Under Endpoint users, in the User type field, select either User or User group.

c.     In the Application user or group field, select a valid Microsoft Dynamics AX user or user group name

For our purpose on the Users Tab follow the steps below:

i.    On the “Users” tab, press (CTRL + N) for associating the new User / Groups

ii.    Select “User Group” under User type and “Admin” from the list under Application user or group

image017

 

In order for the Application Integration Framework (AIF) to begin sending and receiving documents with adapters, four services must be running as batch jobs within Microsoft Dynamics AX:

a.       AIFOutboundProcessingService

b.      AIFInboundProcessingService

c.       GatewaySendService

d.      GatewayReceiveService

 

Until these batch jobs are started, no documents can be processed in adapter-based exchanges. Inbound documents do not enter your Microsoft Dynamics AX system and outbound documents accumulate in the AIF outbound processing queue.

Refer the link below for more details.

http://msdn.microsoft.com/en-us/library/aa570105(AX.10).aspx

In next article I would be continuing the series and would be explaining what needs to be configured in order to “Send Data from BizTalk to Dynamics AX”.

Posted by ashishme | 1 Comments

Enabling SQL Dependency in SQL Server Database

This script would help you to enable the SQL Dependency on SQL Server Database.

 

You simply needs to replace the “domain\login” with either the SQL Server Login User or Windows User under which the SQL dependency should work. Please execute the script as an administrator role. You might require to restart the SQL Server service.

 

Code Snippet
use [Master]

-- Ensuring that Service Broker is enabled - replace the Database with the desired Database name
ALTER DATABASE [Database] SET ENABLE_BROKER
GO 

-- Switching to our database - replace the Database with the desired Database name
use [Database]

IF EXISTS(SELECT 1 FROM sys.schemas WHERE NAME='domain\login')
BEGIN
DROP SCHEMA [domain\login]     
END
GO

CREATE SCHEMA [domain\login]
GO
 
IF NOT EXISTS(SELECT 1 FROM sys.syslogins WHERE NAME='domain\login')
BEGIN
  CREATE USER [domain\login] FOR LOGIN [domain\login] 
  WITH DEFAULT_SCHEMA = [domain\login]
END;
GO

ALTER USER [domain\login] 
WITH DEFAULT_SCHEMA = [domain\login]
GO 

ALTER AUTHORIZATION ON SCHEMA::[domain\login] TO [domain\login]
GO


IF NOT EXISTS(SELECT 1 FROM sys.database_principals WHERE NAME='sql_dependency_subscriber' AND type ='R')
BEGIN
CREATE ROLE sql_dependency_subscriber AUTHORIZATION [domain\login]
END
GO

ALTER AUTHORIZATION ON ROLE::[sql_dependency_subscriber] TO [domain\login]
GO

-- Permissions needed for [sql_dependency_subscriber]
GRANT CREATE PROCEDURE to [sql_dependency_subscriber] 
GRANT CREATE QUEUE to [sql_dependency_subscriber]
GRANT CREATE SERVICE to [sql_dependency_subscriber]
GRANT REFERENCES on 
CONTRACT::[http://schemas.microsoft.com/SQL/Notifications/PostQueryNotification]
  to [sql_dependency_subscriber] 
GRANT VIEW DEFINITION TO [sql_dependency_subscriber] 

-- Permissions needed for [sql_dependency_subscriber] 
GRANT SELECT to [sql_dependency_subscriber] 
GRANT SUBSCRIBE QUERY NOTIFICATIONS TO [sql_dependency_subscriber] 
GRANT RECEIVE ON QueryNotificationErrorsQueue TO [sql_dependency_subscriber] 
GRANT REFERENCES on 
CONTRACT::[http://schemas.microsoft.com/SQL/Notifications/PostQueryNotification]
  to [sql_dependency_subscriber] 

-- Making sure that my users are member of the correct role.
EXEC sp_addrolemember 'sql_dependency_subscriber', 'domain\login'

 

 

 

 
Posted by ashishme | 1 Comments
More Posts Next page »
 
Page view tracker