(For more resources related to this topic, see here.)

Registering services in UDDI

Thanks to the ESB Toolkit, we can easily populate our organization's services registry in UDDI with the services that interact with the ESB, either because the ESB exposes them or because they can be consumed through it.

Before we can register service in UDDI we must first configure the registry settings.

Registry settings

The registery settings change how the UDDI registration functionality mentioned in preceding section behaves.

• UDDI Server: This sets URL of the UDDI server.
• Auto Publish: When enabled, any registry request will be automatically published. If it's disabled, the requests will require administrative approval.
• Anonymous: This setting indicates whether to use anonymous access to connect to the UDDI server or to use the UDDI Publisher Service account.
• Notification Enabled: This enables or disables the delivery of notifications when any registry activity occurs on the portal.
• SMTP Server: This is the address of the SMTP server that will send notification e-mail messages.
• Notification E-Mail: This is the e-mail address to which to send endpoint update notification e-mail messages.
• E-Mail From Address: This is the address that will show up as sender in notification messages sent.
• E-Mail Subject: This is the text to display in the subject line of notification e-mail messages.
• E-Mail Body: This is the text for the body of notification e-mail messages.
• Contact Name: This setting is name of the UDDI administrator to notify of endpoint update requests.
• Contact E-Mail: This setting is used for the e-mail address of the UDDI administrator for notifications of endpoint update requests.

The following screenshot shows all of the settings mentioned in preceding list:

In the ESB Management Portal, we can see in the top menu an entry that takes us to the Registry functionality, shown in the following screenshot:

On this view, we can directly register a service into UDDI. To do this, first we have to search the endpoint that we want to publish. These can be endpoints of services that the ESB consumes through Send ports, or endpoints of services that the ESB exposes through receive locations.

As an example, we will publish one of the services exposed by the ESB through the GlobalBank.ESB sample application that comes with the ESB Toolkit.

First, we will search on the New Registry Entry page for the endpoints in the GlobalBank.ESB application, as shown in the following screenshot:

Once we get the results, we will click on the Publish link of the DynamicResolutionReqResp_SOAP endpoint that actually exposes the /ESB. NorthAmericanServices/CustomerOrder.asmx service. We will be presented with a screen where we can fill in further details about the service registry entry, such as the service provider under which we want to publish the service (or we can even create a new service provider that will get registered in UDDI as well).

After clicking on the Publish button at the bottom of the page, we will be directed back to the New Registry Entry screen, where we can filter again and see how our new registry entry is in Pending status, as it needs to be approved by an administrator.

We can access the Manage Pending Requests module through the corresponding submenu under the top-level Registry menu. There we can see if there are any new registry entries that might be pending for approval.

By using the buttons to the left of each item, we can view the details of the request, edit them, and approve or delete the request.

Once we approve the request, we will receive a confirmation message on the portal telling us that it got approved. Then, we can go to the UDDI portal and look for the service provider that we just created, were we will see that our service got registered.

The following screenshot shows how the service provider of the service we just published is shown in the UDDI portal:

In the following screenshot we can see the actual service published, with its corresponding properties.

With these simple steps, we can easily build our own services registry in UDDI based on the services our organization already has, so they can be used by the ESB or any other systems to discover services and know how to consume them.

Understanding the Audit Log

Audit Log is a small reporting feature that is meant to provide information about the status of messages that have been resubmitted to the ESB through the resubmission module. We can access this module through the Manage Audit Log menu.

We will be presented with a list of the messages that were resubmitted, if those were resubmitted successfully or not, and even check the actual message that was resubmitted, as the message could have been modified before being resubmitted.

Fault Settings

On the Fault Settings page we can specify:

• Audit Options: This includes the type events that we want to audit:
  • Audit Save: When a message associated with a fault is saved.
  • Audit Successful Resubmit: When a message is successfully resubmitted.
  • Audit Unsuccessful Resubmit: When the resubmission of a message fails.
• Alert Queue Options: Here we can enable or disable the queuing of the notifications generated when a fault message is published to the portal.
• Alert Email Options: Here we can enable and configure the service that will actually send e-mail notifications once fault messages are published to the portal. The three most important settings in this section are:
  • Email Server: The e-mail server that will be actually used to send the e-mails.
  • Email From Address: The address that will show up as sender in the e-mails sent.
  • Email XSLT File Absolute Path: The XSLT transformation sheet that will be used to format the e-mails. The ESB Toolkit provides one, but we could customize it or create our own sheet according to our requirements.

Summary

In this article, we discussed the additional features of the ESB Management Portal.

We learned about the registry settings, which are used for configuring the UDDI and setting up the e-mail notifications. We also learned how to configure fault settings and how to utilize the Audit Log features.

Resources for Article :

Further resources on this subject:

• Microsoft Biztalk server 2010 patterns: Operating Biztalk [Article]
• Setting up a BizTalk Server Environment [Article]
• Communicating from Dynamics CRM to BizTalk Server [Article]