I was building an External Web Service the other day, when I noticed that the message format exposed by the external application relied, rather heavily, on XML attributes. For example:
<AddressLine lineNumber="1">My House</AddressLine>
<AddressLine lineNumber="2">My Street</AddressLine>
I wanted to use the Declarative UI Data Mapper to bring this information into my Contact BC model and had immediate concerns about the use of attributes.
I needn’t have worried, as the WSDL import process does something rather clever with the Integration Object for the external message structure.
What I found was that the import wizard created IC fields for each of my attributes:
The “type” and “lineNumber” IC fields have an “XML Style” property of “attribute”, allowing the EAI mapping engine to map between the IO instance and resulting XML message without losing the context of the data.
I was also then able to use the EAI Data Mapper, by means of a Source Component Search Spec, to retrieve the “first” and “last” names for use in my internal IO instance.
I love the integration capabilities of Siebel and have yet to find a requirement that cannot be met by declarative means.
I blogged a while back about a third party Email Service Provider (ESP) called dotMailer. They provide a rather snazzy email marketing capability that far surpasses the function of the Siebel Email Marketing Server. They also expose a very functionally rich API via SOAP WebServices and I have been looking at building a Siebel Wrapper to allow the use of dotMailers services in the Siebel Marketing application.
What I’ve put together so far are a number of components:
- Central, configurable parameters to support access and authentication
- Workflow processes, wrapping the dotMailer API in comprehensive, neat and standardised Siebel configuration
- Includes a template Exception Workflow to allow you to hook into your existing exception framework. This is configured as the exception workflow in all the supplied Workflow Processes
- Example workflow showing hooks into the Campaign Launch functionality, effectively replacing the Siebel Email Marketing functionality with that of dotMailer
- Simplified but extensible IOs supporting query and update of Contacts and Campaigns, including history and responses
- Hierarchical data maps providing standard mappings from dotMailer constructs to Contact and Campaign IOs and vice versa
- Simple, well documented and structured eScript business service providing supporting services in a single, re-usable and customisable form
- A simple administration applet and view to embed the dotMailer UI in your Siebel Marketing application
Now, this is very much a work in progress and something that I’m doing in my spare time – with a second baby well on the way (WOO HOO!) it may take me a while to get a Production ready product.
What I’d like to do is gauge any interest my readership may have in this endeavour. Are you a Siebel Marketing developer? Customer? Prospect? Are you looking to replace Siebel Email Marketing?
A click in the survey below would be greatly appreciated as it will help me gain an understanding of interest in this little project and may motivate me to get it completed ahead of schedule!
Thanks for reading!
Recently, while attempting to resolve an outbound Web Service issue, I came across, quite old, blog topics on Siebel EAI and how to remove empty tags from an outbound SOAP message. Pretty much all of them involved some sort of jiggery pokery and / or script. However, I came across my own method, pretty much by mistake, that I’d like to share.
It’s undocumented, but it would appear that the the CSSWSOutboundDispatcher class, on which outbound WS proxy business services are based, supports the “siebel_ws_param:RemoveEmptyTags” parameter.
So, removing empty tags is a simple as including this as an input parameter in your call to the proxy BS:
It’s as easy as that!
I love all these ‘undocumented’ BS properties but I do wish they were documented in Bookshelf so that we, as developers, can make full use of the declarative capabilities of Siebel.
So, let’s get the easy bits out of the way first!
dotMailer provide access to their services via SOAP web services. As such, they provide a Web Services Definition Language (WSDL) file that provides all of the details around the data structures used, to be translated into Siebel Integration Objects, and methods that can be invoked, provided by the Siebel Outbound Web Service definition and proxy Business Service.
Take a look here and you’ll find the WSDL for the integration services provided by dotMailer. Simply download this file and fire up Siebel Tools. From here:
- Create a new Project for our custom objects
- Select ‘File > New Object > EAI > Web Service’
- Select your project, WSDL and click ‘Next’, click the ‘DeployCheckbox’ then ‘Finish’
- You’ll find a new Business Service called ‘APISoap’ – rename this to something a bit more descriptive, like ‘dotMailer BS’
- Check out the methods exposed in the new BS – lots of lovely functionality to send and monitor marketing emails!
- Have a look at the Integration Objects created – you’ll find message formats for all the outbound and inbound message structures that you’ll need to manage the integration
- Go to ‘Administration – Web Services’ in the client and have a look for the ‘API’ Web Service. Here’s you’ll find the URL for the dotMailer API, along with all the supported service ports and operations
And that really is that!
In order to test, you can create a simple Workflow that invokes the ‘GetServerTime’ function. This doesn’t require any input or authentication, so is a good test of your set up so far:
- Create a new Workflow Process in your new Project
- Add Start, Business Service and End steps
- Add a new Process Property:
|Name||Data Type||Integration Object
- Modify the Business Service step, setting the following properties:
|Name||Business Service Name||Business Service Method
|dotMailer GetServerTime||dotMailer BS||GetServerTime
- Set the outputs of the step as follows:
|Property Name||Type||Integration Object||Output Argument
- Run the Workflow and be amazed by the result:
Over the coming months I’ll be looking at how we might develop a framework to replace the calls to Siebel Marketing Server with calls to the dotMailer Web Service.
See you soon!
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:
- In testing terms, it’s great to collect a load of test cases that can be submitted to external systems via SOAP UI
- For debugging, it’s useful to see exactly what XML Siebel is pushing to the external system
- It’s not always easy engaging Middleware people to trawl through their logs and audit trails to retrieve messages
- 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:
- Download Wireshark
- Install it on your Siebel app server (where the outbound call will be made, be that by an OM or Workflow Process Manager)
- Run Wireshark
- Click Capture Options and add the following filter, subtituting the IP address of the DESTINATION of the outbound Web Service:
- Click Start
- Within the Siebel Client, perform whatever process it is that triggers the outbound interface
- Back in Wireshark, you should see some activity – start at the top and work your way down, looking at the capture TCP packets
- You’ll eventually find what you’re looking for – a packet containing the XML sent by your Siebel application!
- Right click the packet and select Copy > Bytes > Printable Text Only
- 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.