Using Wireshark to trace EAI messaging

October 25, 2011 By Leave a Comment

If, like me, you’ve come on to a project where the development has pretty much already been done, you may come across aspects of the Siebel configuration that you may have done differently.

In EAI terms, something that I always find useful is an audit mechanism to trap and log XML generated via an outbound EAI call. The reasons are many:

  1. In testing terms, it’s great to collect a load of test cases that can be submitted to external systems via SOAP UI
  2. For debugging, it’s useful to see exactly what XML Siebel is pushing to the external system
  3. It’s not always easy engaging Middleware people to trawl through their logs and audit trails to retrieve messages
  4. If you ever need to re-send a message, it’s great to have the original source there and waiting

Now, the ideal would be to have Siebel audit the XML as part of the outbound workflow: either store it in the database, file system or as a physical file elsewhere in the estate. Obviously, this isn’t always done and you have to live with it.

As an alternative, you can use Wireshark to trap outbound messages, allowing you to address 3 of the 4 areas above – I’ll let you work out which!

To set up Wireshark and monitor outbound Siebel EAI messages, follow these simple steps:

  1. Download Wireshark
  2. Install it on your Siebel app server (where the outbound call will be made, be that by an OM or Workflow Process Manager)
  3. Run Wireshark
  4. Click Capture Options and add the following filter, subtituting the IP address of the DESTINATION of the outbound Web Service:

    5. host xxx.xxx.xxx.xxx

  5. Click Start
  6. Within the Siebel Client, perform whatever process it is that triggers the outbound interface
  7. Back in Wireshark, you should see some activity – start at the top and work your way down, looking at the capture TCP packets
  8. You’ll eventually find what you’re looking for – a packet containing the XML sent by your Siebel application!
  9. Right click the packet and select Copy > Bytes > Printable Text Only
  10. Paste into notepad and you’ll see the complete, SOAP wrapped XML document

Wireshark can be a bit fiddly to use to begin with. It’s a good idea to apply a sensible filter before starting capture or you’ll get all sorts of junk to wade through.

Enjoy!

VN:F [1.9.13_1145]
Rating: 0.0/10 (0 votes cast)
Filed Under: Siebel, Web Services Tagged With: , ,

Siebel and WordPress – Workflow and Web Service

June 4, 2011 By 1 Comment

Okay, now we’ve got our proxy BS, Integration Objects and Web Service definitions all in Siebel, we can build a Workflow Process to invoke (consume) the Web Service and do something useful with the integration interface.

We’ll start with a pretty simple requirement – let’s look for the first post from the WordPress site and create a Siebel Action (Activity) record with the information.

  1. First up, create a new Data Map (Site Map > Integration – Administration > Data Map Editor)
  2. The Integration Objects that we’re going from and to are ‘Post’ and ‘Action_IO’ respectively
  3. The Integration Components are ‘Post’ and ‘Action’
  4. Map the [title] field from WordPress to the ‘Description’ field in Action and map the [content] field to ‘Comments’
  5. Map the [id] field to ‘Activity UID’ to give us a user key to play with
  6. Validate your new Data Map

Now let’s create a new Workflow Process.

  1. Create a new Workflow Process in the project that we created last time.
  2. You’ll need to define some new process properties:
    3. PropertyTypeDefaultComment
    WP Post IdString1Use this to store a literal for testing purposes
    WP Post MessageHierarchyThe Hierarchy we’ll use to grab data from WordPress
    WP Action MessageHierarchyThe Hierarchy we’ll use to store the new Action definition
  3. Create a new Workflow Process with the following steps:
    4. NameTypeBusiness ServiceMethodComment
    StartStart
    Get WP PostBusiness ServiceWordPressWebServicePortTypegetPostProxy BS that invokes the Web Service
    Purge Data MapBusiness ServiceEAI Data Transformation EnginePurgeRefreshes the Data Map cache for testing
    Data MapBusiness ServiceEAI Data Transformation EngineExecuteMap the WP data to the Action IO
    Insert ActivityBusiness ServiceEAI Siebel AdapterInsertCreates the new Action BC record
    EndEnd
  4. The first business service should be configured to run the proxy business service and the getPost method. Input should be the WP Post Id and the output will be the WP Post Message. Note that the output argument from the proxy BS is ‘getPostResponse:getPostReturn’
  5. Next, invoke the Purge method of the EAI Data Transformation Engine BS. This is good practice for testing but should be removed in a Production environment
  6. Now call the Execute method of the EAI Data Transformation Engine BS. Pass in the WP Post Message hierarchy, the name of the Data Map created earlier and output the WP Action Message property. This will give us our ‘Action’ IC with all the Integration Component Fields in place
  7. Finally, call the ‘Insert’ method of the EAI Siebel Adapter BS. This will take as input the hierarchy created by the mapper and use it to create a new Activity record

That’s it!

Run through the simulator and you’ll see that the process calls the Web Service that you created to grab an XML message from your WordPress site into a hierarchy. The Data Mapper then uses the IO definitions created by the EAI wizard to map the data across to the vanilla Action IO. Finally, the process uses the mapped message to create a new Activity record in Siebel!

Give it a go and post if you have any questions!

 

VN:F [1.9.13_1145]
Rating: 10.0/10 (4 votes cast)
Filed Under: Configuration, Siebel, Technology, Web Services Tagged With: , , ,

Siebel and WordPress Integration

June 3, 2011 By 2 Comments

I read a really interesting requirement posted on the Oracle Siebel Forum the other day:

Any one of you tried to connect WordPress and Siebel via WSDLs – SOAP, API scripts?

It got me thinking – how difficult could this be? Well, let’s find out!

Here’s what I did:

In WordPress:

  1. From your WordPress site, add a new plugin and search for the ‘Wordpress Web Service’ plugin. Install it and activate the plug in
  2. Navigate to the WPWS URL on your blog: http://<Your BLOG URL>/index.php/wpws
  3. Click the WSDL URL and save the WSDL file off on your local hard disk

 

This gives you the Web Service definition (WSDL) file that you can import into Siebel Tools.

In Siebel Tools:

  1. Create a new project and lock it – ‘OLI – WordPress’
  2. Go to File > New > EAI > Web Service
  3. Pick the new Project and open the WSDL file that you saved above, picking all the defaults
  4. Let the Siebel EAI wizard do it’s thing

You’ll end up with a Proxy Business Service, a bunch of Integration Objects / Components and a WSDL definition that you can choose to automatically deploy to your connected database. You can now invoke the Proxy BS in Workflow, using the IO’s that have been created for you, to consume the Web Service exposed by your WordPress site.

You can also import the WSDL into SOAP UI and ping off a test message, just to see what you get back with each of the messages. I’m going to use the ‘getPost’ method in the next steps so give that a try now.

Right, we now have a mechanism to integrate Siebel and WordPress. Always one to keep the tension high, I’m going to leave the details of how to build a Workflow Process to call the new Web Service until the next post!

VN:F [1.9.13_1145]
Rating: 10.0/10 (3 votes cast)
Filed Under: Configuration, Siebel, Technology, Web Services Tagged With: , , ,

Inbound Web Service – Part 4 – Testing

February 17, 2010 By Leave a Comment

Our Web Service is complete – now we can use soapUI to test it.

  1. First up, make sure everything is deployed:
    • SRF - compiled and deployed to the server
    • Workflow Process – Deployed through Tools and Activated through the Web Client. Double check that the Integration Object property has been set against the ‘SiebelMessage’ process property
    • Web Service – click the ‘Clear Cache’ button in the Inbound Web Services view to ensure Siebel can process incoming requests
  2. Launch soapUI and create a new project via File > New soapUI project
  3. Give the project a name of ‘My Siebel Web Service’ and browse for the WSDL file that we generated last time. Leave the ‘Create Requests’ checkbox as the only one checked for now
  4. In the navigator on the left you’ll see you project. Beneath that, you’ll see your Web Service and the ‘port’ that we exposed in Siebel – getCustomerDetails. Beneath that is a sample request called ‘Request 1′. Double click it
  5. soapUI will use the WSDL to construct a SOAP message in the format Siebel will expect. This includes a handy placeholder for the ‘CustNum’ input property. Populate this will a ROW_ID of a Contact from your server environment
  6. Click the green ‘Submit Request’ button in the top left of the window. soapUI will use the URL that you gave in the Web Service definition, as it’s now part of the WSDL. It will submit the package via HTTP to your Siebel Web Server
  7. On receipt, the SWE will pass the message contents on to the appropriate object manager for processing, returning the response back to the caller
  8. In the right side pane of soapUI, you should shortly see a response in the format defined in the IO that we created in Part 1!
    • If the response looks garbled, go to File > Preferences, HTTP Settings and uncheck ‘Accept compressed responses from hosts’

And that, as they say is that.

I hope you have enjoyed this series of articles and that you have learned a little about Web Services and their application in Siebel.

Next time, we’ll take a look at Outbound Web Services, where Siebel can be configured to consume functionality exposed through external applications.

VN:F [1.9.13_1145]
Rating: 10.0/10 (1 vote cast)
Filed Under: Siebel, Web Services Tagged With: ,

Inbound Web Service – Part 3 – Web Service

February 14, 2010 By 4 Comments

Now that we have our IO and Workflow Process defined, we can look at exposing these through a Web Service. Luckily, Siebel has a number of functions that will allow us to do this quickly and easily!

  1. Having tested the Workflow Process that we created last time, check in the IO and Workflow Process. Compile and deploy an SRF and deploy the Workflow Process through Administration > Business Processes > Workflow Deployment
  2. Here comes the easy part! In Siebel Tools, connected to the Server data source, locate your Workflow Process, right click and select ‘Deploy As Web Service…’
  3. The ‘operation name’ is the ‘port’ that the external system will refer to. Think of this as a function name in a class or Business Service definition. Specify a value of ‘getCustomerDetails’
  4. The URL of the Web Service is the URL on which the external system will communicate with the Object Manager supporting the Workflow process. For example:
    • http://myhost/eai_enu/start.swe?SWEExtSource=WebService&SWEExtCmd=Execute&WSSOAP=1
    • Stick to this template for now – you can always change it later and we’ll see how to do so shortly
  5. Leave ‘Generate WSDL’ unchecked for now and click ‘Finish’
  6. Now log into the application thin client. Navigate to Site Map > Administration – Web Services > Inbound Web Services and query for ‘My Web Service Workflow’. Siebel will have set it all up for you, based on the properties of the Workflow Process
  7. In order to get things working quickly, make a few changes to the Service Port. Be sure to set the login details appropriately. This allows the external application to call the Web Service without having to supply authentication details:
    • Binding: SOAP_RPC_LITERAL
    • Address: http://myhost/eai_enu/start.swe?SWEExtSource=SecureWebService&SWEExtCmd=Execute&UserName=SADMIN&Password=SADMIN
  8. Click the ‘Generate WSDL’ button and save the resulting file somewhere safe
  9. Click the ‘Clear Cache’ button, to force a referesh of Siebel’s Web Service cache – if you don’t do this, you’ll get an error when you try to call the Web Service

You have now created a Siebel Web Service that can be called remotely, from any machine with access to your Web Server.
In the next post, I’ll explain how to test this and see some useful results.

VN:F [1.9.13_1145]
Rating: 10.0/10 (1 vote cast)
Filed Under: Siebel, Web Services Tagged With: ,
Next Page »