Sonic Connect Service - Lessons Learned

I recently had to migrate some of our old Sonic 7.6 Processes over to the new Sonic 8.0 environment. This mostly involved getting Sonic's new Connect Service integrated. Below are my lessons learned that you will not find in the documentation or on the community.

Project Background:

My project invovles doing 3 types of requests: POST, PUT and DELETE. We have a RESTful Web Service setup for adding new users (POST), assigning books to users (PUT), and removing books from users (DELETE). There were a lot of different things we had to research via trial and error, that you cant find in the documentation.

Setting Request Headers:

By default, you can set the Accept Header (called: Accept), Request Method (called: Method), Request URL (called: Base Url), and Body (called: PostData). We had the need to set Content-Type as well. Sonic Connect Service appears to use JMS Headers for the Request Headers. To add Content-Type, simply use a Mapping Service to add the Request Header and its value to the JMS Header section, in this case Content-Type, and set its value. Example Message Structure:

Message

- ESB Headers

- JMS Headers

     - Content-Type : "text/xml"

- Part 0

- Part 1

Handling Web Service Error Codes:

Sonic Connect Service has the ability to monitor the returned Error Codes and perform different things based on that code. By default, any code greater than 300 and less than 999, will get handled by a FaultHandler. In our case of adding new users, this wasnt true, as we returned a 409 for a User Already Exists, and didnt want to fail on that. To change the default behavior, open the spring.xml file that comes along with your Connect Service, and locate the following line:

  <bean id="GlobalGenericRestInvocationErrorStatusRange1" class="com.progress.sonic.esb.camel.util.Range">
    <property name="from" value="300"/>
    <property name="to" value="999"/>
  </bean>

Simply change the rules here. For us, we made the "from" value, be 998, since we wanted to handle the 409 and other 400 error codes in the process.

Working with Zero-Length Body's such as PUTs and DELETEs:

Our PUT and DELETE requests does not submit a body. It uses REST protocols to add and remove entities. The example for removing a book from a user:

Method: DELETE

URL: http://myhost.com/userservice/users/{userid}/books/{bookid}

Executing a DELETE, will remove the provided bookid from that user.

Our process works as follows: We send data to the ESB via HTTP Accpectors, which then land on a Topic which then goes through the selected process (in this case the Remove Book from User Process). The issue we ran into, is that when you submit data via the HTTP Acceptor into the ESB, a JMS Header variable called Content-Length gets created from that beginning input. When your message finally arrives at the Sonic Connect Service, it still has the Content-Length varibale set. The Service attempts to perform a DELETE, but thinks it has data to send as well (based on the header), and eventually times out (Thros an exception to be exact). We discovered, that we had to remove that Header or set it to 0(Zero) so that it didnt fool the Connect Service. This is all based off my first item above, that Sonic Connect Service uses JMS Headers as the Request Headers, so always be sure to check whats in there.

Let me know if there is anything else you need help with, as we spent a good week digging through this great new Service!

Thanks

Wes