Tag: REST

Using the SO-Aware PowerShell Provider to Register Services

With the creation of SO-Aware ( http://www.tellagostudios.com ) , a Service Metadata Repository that can do all sorts of things, comes the added benefit of using Microsoft’s Windows PowerShell. To borrow a line from Microsoft’s site, PowerShell is a command line shell and scripting language that helps IT professionals achieve greater control and productivity to more easily control system administration and accelerate automation. We at Tellago Studios, implemented a set of over 40 different standard command line tools to help with the management and control of the SO-Aware Repository. Outlined below are the steps needed to install, register, configure and add SOAP and RESTful Services inside SO-Aware.

How To Install the SO-Aware PowerShell Provider

  1. First Download the PowerShell Provider Setup files here: http://www.tellagostudios.com/projectfiles/SO-Aware_PowerShell.zip
  2. Next extract the files to a directory of your choosing and execute the SO-Aware PowerShell.msi windows installer file as an administrator.
  3. Step through the setup dialogs as such:
  9. After the install has successfully completed, the SO-Aware powershell provider named: “SOAwareSnapIn” are registered to the PowerShell global system. To utilize the SO-Aware commandlets you must open a PowerShell Session and add the SOAwareSnapIn to the current session. At this point, the SO-Aware powershell commandlets can be used.

Working with a PowerShell Session

  1. Open up a PowerShell prompt using Windows Server 2008 (See an icon that looks similar to this:
  2. Inside the PowerShell Command prompt type: add-PSSnapIn SOAwareSnapIn
  3. The above line adds the SO-Aware PowerShell commandlets into the current PowerShell Session. Each session you start up will need to have the snapin added in order to use the SO-Aware PowerShell commmandlets. (There are scripts the you can run in order to alleviate this repetitive process, after the install just navigate to Start->All Programs-> Tellago Studios->SO-Aware->SOAware.ps1)
  4. After you’ve loaded up all the SO-Aware commandlets, we must configure the current SO-Aware PowerShell Provider session to point to the SO-Aware Service Repository. Type in: set-SWEndpoint –url ‘http://localhost:8088/SO-Aware/ServiceRepository.svc’ (Just remember to replace the actual URL with your URL pointing to the SO-Aware Service Repository.

Registering a SOAP Service inside the SO-Aware Repository

  1. To Add any type of service, REST, ODATA or SOAP we use the add-swservice commandlet. To determine exactly which service type we use the Style property.
  2. Inside the PowerShell Command prompt type:    add-swservice -Name ‘People Finder’ -Namespace ‘http://tempuri.org’ -Style ‘SOAP’
  3. Style supports three options: SOAP, REST, ODATA

  5. You should see text that says that the Service was added successfully, otherwise an error will pull up showing you the issue such as:

  7. To complete the Service Registration, we need to Add a ServiceVersion inside the ServiceRepository and attach it to the newly added service.
  8. To Add a Service Version, we use the add-sw[Type]ServiceVersion command let, where [Type] can be either REST, OData, or, SOAP.
  9. However to add the Service Version we first need the Service ID of the newly added service, thus use the get-swServices commandlet to retrieve the newly added service, Service Id
  10. Type: get-swServices –Name ‘People Finder’
  11. This will retrieve all services with the name ‘People Finder’, you could actually leave –Name off and all services registered would return:

  13. When you master PowerShell, you can also filter out values, and pipe it’s contents into other commandlets, such that all I really needed was one command to get the ServiceID, and pass it’s value into the Add Service Version commandlet.
  14. Now that we have the service id, we can add it to the Service Version using the add-swSoapServiceVersion commandlet.
  15. Type: add-swSoapServiceVersion –ServiceId ‘eab4cad9-e0ad-4fd7-941c-2f3641dd89e5’ –Version ‘1.0’ –url ‘http://localhost:1245/PeopleFinder.svc?wsdl‘ –Configuration ‘Production’
  16. Where the ServiceID is the actual Guid from your service, the Version is the actual version number you want to add, Configuration is the category name you want to file the Service Version under, and the Url is the live url location to your WSDL for the SOAP Service.

  18. That’s it. You’re done!
  19. Goto to your SO-Aware Web Site and see your results:
  20. Added Service
  21. Added Service Version:
  22. Added Version Details, inferred from WSDL

Registering a REST and OData Service inside the SO-Aware Repository

  1. To Add either REST or ODATA we use the add-swservice commandlet.
  2. Inside the PowerShell Command prompt type:    add-swservice -Name ‘REST WebService’ -Namespace ‘http://localhost/WebStyle.Host/Service.svc’ -Style ‘REST’
  3. Style supports three options: SOAP, REST, ODATA

  5. You should see text that says that the Service was added successfully
  6. To complete the Service Registration, we need to Add a ServiceVersion inside the ServiceRepository and attach it to the newly added service.
  7. To Add a REST Service Version, we use the add-swRESTServiceVersion command let other than that we use the add-swODataServiceVersion.
  8. However to add the Service Version we first need the Service ID of the newly added service, thus use the get-swServices commandlet to retrieve the newly added service, Service Id
  9. Type: get-swServices –Name ‘REST WebService’
  10. This will retrieve all services with the name ‘REST WebService’, you could actually leave –Name off and all services registered would return:

  12. Now that we have the service id, we can add it to the Service Version using the add-swRESTServiceVersion commandlet.
  13. Type: add-swRESTServiceVersion –ServiceId ‘7ea50e22-7262-4d09-8611-07cf62e8e555’ –Version ‘1.0’ –BaseUri ‘http://localhost:4371/WebStyle.Host/Service.svc ‘ –Configuration ‘Production’
  14. For OData we’d use:
  15. Type: add-swODataServiceVersion –ServiceId ‘7ea50e22-7262-4d09-8611-07cf62e8e555’ –Version ‘1.0’ –ODataUrl ‘http://localhost:4371/WebStyle.Host/Service.svc ‘ –Configuration ‘Production’
  16. Where the ServiceID is the actual Guid from your service, the Version is the actual version number you want to add, Configuration is the category name you want to file the Service Version under, and the BaseUri is the live url location to your Rest Service, or the ODataUrl is the live url location to your REST OData Service.

  18. That’s it. You’re done!
  19. Goto to your SO-Aware Web Site and see your results:

  21. Service Version details:
  23. What you’ll notice here, is that for this version of the SO-Aware PowerShell Commandlets, REST Add Operations are not supported yet, thus you’ll have to Add the operation using the Web based UI manually.

Working with some of the remaining SO-Aware Commandlets

  1. Case in point here, all SO-Aware Commandlets will follow a simple pattern:
    1. GET-SW*s
    2. ADD-SW*
    3. SET-SW*
    4. REMOVE-SW*
    5. Where the “*” is the name of the artifact or entity you’d like to query or update.
  2. So for example if you wanted to get all services you would use: GET-SWServices
  3. To see which parameters that are needed for each commandlet, you can just execute the commandlet inside the PowerShell prompt and the PowerShell prompt will ask you for the required parameters.
  4. To see any optional parameters, you’ll need to download the documentation at: http://tellagostudios.com/sites/default/files/SO-Aware%20API%20Documentation.zip

64Bit – WCF Custom Isolated – REST – “504” response

Tonight my fellow Tellago-ans, and I ran into a issue using the WCF-CustomIsolated Adapter on Windows Server 2008 64bit.

We were trying to use the .Net 3.5 bindings/REST styled architecture to support HTTPv1.1 Posts into BizTalk using the WCF CustomIsolated Adapter. In our lab and development environments, process worked like a charm. We used HTTP Fiddler to test the data and message flow. Here’s an example of what I mean:

In the above screen shot, we have configured a WCF-CustomIsolated adapter to use the .Net 3.5 WebHTTPBinding. (Instructions on how to do this can be found in Adrian’s blog). When using Fiddler, we can easily make posts into the BizTalk Server:

And our response we would receive would be something similar to this:

 

However upon moving our solution to a 64bit BizTalk Server running on IIS 7.0 (64bit Mode), the HTTP Post no longer worked. We started receiving “504” gateway issues.

Now oddly enough these servers were behind a firewall; we did need VPN accounts and software to access these servers; and also to mention, to get any internet access we went through a web proxy. This would lead any logically thinking person to believe the problem lie in one of these culprits: Firewall, VPN, or proxy…

Not so fast says the turtle!!!

Well, we started looking more into this and turned on WCF Tracing and looking into the Event Viewer and saw that we were receiving a weird WCF error. The error was:

The adapter “WCF-CustomIsolated” raised an error message. Details “System.XmlXmlException: Unexpected end of file.

At System.Xml.EncodingStreamWrapper.ProcessBuffer(Byte[] buffer, Int32 offset, Int32 count, Encoding encoding)…

(and on and on…)

 

We did not have a malformed message, after all it was Http Fiddler and we were just typing in a dummy xml message like “<Blah/>” and the WCF Adapter was failing horribly on the 64bit machine, where as the 32bit machine ran like charm… We started to think maybe it was an encoding issue, or something…

So Here’s the WTF for the day!!!

It turns out the issue lie in the fact that the WebHttpBinding element by default utilizes the transferMode set to Buffered.

Apparently there is an issue when trying to use this setting on a win64 bit OS, with IIS 7.0 in 64bit mode, with BizTalk WCF-CustomIsolated adapters… Our fix:

You guessed it: set the transferMode property to Streamed issue resolved.