Select Page

An ‘Active Users’ view using Server Manager and a VBC

I’ve recently implemented a very interesting requirement using my old favourite, the Virtual Business Component (VBC). VBCs are great and allow you to build your own recordset beneath a virtual BC definition that behaves (almost) exactly like an old fashioned BC.


The steps to create a VBC are easy peasy:

  1. Create a new BC record, in Siebel Tools, specifying the class ‘CSSBCVExtern’. Call it ‘OLI – User Sessions VBC’
  2. Create a User Property on your new BC, called Service Name. Give it a value, ‘OLI – User Sessions BS’
  3. Create a couple of fields in your VBC: ‘CC Alias’ and ‘OM Login’, both as DTYPE_TEXT
  4. Create a new Business Service called ‘OLI – User Sessions BS’:
  5. You’ll need an ‘Init’ method:
  6. and you’ll need a ‘Query’ method:
  7. Create a new Applet and a new View using the Tools Wizards
  8. Add the view to a new or existing Screen
  9. Add the view to a Responsibility
  10. Job done!

I really, really like VBCs – you gain a lot of control over what you’re bringing into a record set.

Note you’ll need to set the ‘AdminRoles’ configuration parameter on Server Manager and set NSAdminRole in gateway.cfg and namesrvr.cfg, if you want users other than those with ‘Siebel Administrator’ Responsibility to see the results of your hard work!

The “EAI MSMQ Transport” Business Service

Inspire by the “reloaded” Siebel Hub Business Service Library, I felt motivated to write about the “EAI MSMQ Transport” business service. We use MSMQ extensively in my current project and I’m impressed with the simplicity and power of the technology. The JMS equivalent (“EAI JMS Transport”) has it’s own very nice article from @lex and works in much the same way as the MSMQ flavour. What follows is a short summary of some of the key features of the MSMQ technology, used alongside the various EAI functions provided by our favourite enterprise software.

The premise is relatively simple: Microsoft Message Queuing (hereafter refered to as MSMQ) allows systems and processes to communicate in a “fail safe” manner. That is, if the connection between systems were to break or disappear, message communication resumes when the connection is re-established. This is in contrast to socket or point to point communication mechanisms which require an “always on” connection.

Creating an MSMQ queue

Setting up MSMQ is simple, provided “Message Queueing” has been enabled on the Windows host. This is typically enabled via Server Manager on Windows Server hosts and through Windows Features on Windows Client hosts, such as Windows 7.

Creating a queue is equally as straight forward and can be done using PowerShell or via the UI. Via the UI, the process is easy:

  1. Right click ‘My Computer’ and select ‘Manage’
  2. Under ‘Services and Applications’ select ‘Message Queueing’
  3. Expand ‘Private Queues’ to see a list of queues enabled on that machine
  4. Right click ‘Private Queues’ and select ‘New > Private Queue’
  5. Give the queue a name and check the ‘transactional’ checkbox
    • A transactional queue allows blocks of messages to be treated as a single, atomic unit. If MSMQ fails to process that entire block, all messages that have been processed are rolled back
  6. Click ‘OK’ to create the queue


MSMQ introduces the concept of Private, Public, Outgoing and System queues. We use Private queues in order to strictly control which service and administrative users have access to the queues. You can read more about the other queue types on MSDN.

Sending to an MSMQ

Sending XML to an MSMQ is simple, using the “EAI MSMQ Transport” business service. Two methods should peak your interest:

  • Send – this method will send a message to a specified queue. The method is “fire and forget” and Siebel will not be informed of the fate of the message
  • SendReceive – this method will send a message to a specified queue and await a response message. This allows for end to end processing, where the recipient sends either a confirmation of receipt or some sort of response or feedback from a process initiated by the outound message.

Method arguments that you’ll typically use are:

  • <Value> this should be initialised with the XML or text that you want to post to the queue
  • MsmqPhysicalQueueNamethe name of the queue to post to. This should be an MSMQ path such as “private$\mytestqueue”
  • MsmqQueueMachineName – the host name of the machine that contains the target queue. This can be localhost if you’re running everything locally

Using this Business Service method in a Workflow Process is usually combined with calls to the following EAI Business Services:

  • EAI Siebel Adapter.Query – this method creates a Integration Object instance from data in your Siebel Database.
  • EAI TransformationEngine.Execute – this BS method uses a Siebel Data Map to transform an IO instance into an external IO instance with a different schema
  • EAI XML Converter. IntObjHierToXMLDoc – this method tranforms the IO instance into an XML string, ready for transmission to MSMQ

An MSMQ outbound Workflow Process may look something like this:


Running the Workflow, with an appropriate “Object Id” of course, will result in an XML message containing your EAI query results on the queue. You can see it by going back to your MSMQ machine, expand your queue name and click on “Queue Messages”:


You could also invest a few pennies in the MSMQ Explore tool, available exclusively from Ollerenshaw IT Ltd!

Receiving from an MSMQ

Receiving a message is a little more involved, especially if you want Siebel to monito a queue and automatically process messages from it. Three additional elements are required to configure Siebel to systematically process messages from an MSMQ queue. There elements are:

  1. An “MSMQSubsys” profile configuration – this profile details the name and host of the MSMQ queue. The following parameters should be set:
    • MsmqPhysicalQueueName – the name of the queue to post to. This should be an MSMQ path such as “private$\mytestqueue”
    • MsmqQueueMachineName – the host name of the machine that contains the target queue. This can be localhost if you’re running everything locally
  2. A “EAITransportDataHandlingSubsys” profile configureation – this profile configuration specifies what Siebel should do with a message when it is received. Typical scenarios would invoke either a Workflow Process or a Business Service. The following parameters should be set:
    • DispatchWorkflowProcess – <Name of the Workflow process to invoke>
    • DispatchService – Workflow Process Manager
    • DispatchMethod – RunProcess
  3. A  “Enterprise Application Integration Receiver” Component Definition – this component effectively references the two profiles to “poll” the MSMQ and pass received message contents onto the handling Workflow or Business Service. Set the following parameters as a minimum:
    • ReceiverConnectionSubsystem – the name of the MSMQ Queue profile
    • ReceiverDataHandling Subsyst – the name of the Handler profile
    • ReceiverServiceName – EAI MSMQ Transport
    • ReceiverMethodName – ReceiveDispatch
    • Default Tasks – set this to 1 to ensure the component comes up and is listening from when the Siebel Server starts up

A Workflow Process, who’s name you’ll reference in the handler profile above, will look remarkabely similar to the Workflow you created for sending messages, using different methods of the same Business Services:

  • EAI XML Converter. XMLDocToIntObjHier – this method tranforms the XML message back to an Integration Object instance
  • EAI TransformationEngine.Execute – this BS method uses a Siebel Data Map to transform the external IO instance into an internal IO instance with a different schema
  • EAI Siebel Adapter.Upsert – this method applies your IO instance to the business layer, updating and creating data

A receiving Workflow Process may look something like this:


Using listeners and handlers is a mechanism to consistenly poll queues for messages, acting upon them as soon as they are received. It is possible to “manually” receive a message from the queue using one of the three “Receive” methods:

  1. Receive – simply receives / pops the next message from the queue and places it into a property
  2. ReceiveDispatch – receives the next message from the queue and dispatches it to a handling service
  3. ReceiveDispatchSend – receives the next message from the queue, dispatches it to a handling service then sends a response message

MSMQ, and other queuing technologies such as JMS, are a simple and elegant mechanism for providing failsafe, transactional communication between systems. The Siebel EAI business service family provide everything you need, and more, to extract, manipulate and manage structured message data using industry standards. Combined, you have a very easy to use mechanism for Siebel to communicate with the outside world.


MSMQ Test Harness – Updated

I’ve been spending a little time in the evenings, whilst my new baby and exhausted wife have a little sleep, updating and improving some of the tools that I maintain to make my job as a Siebel Consultant easier.

The MSMQ Test Harness application is a very useful tool for testing MSMQ based EAI messaging. It allows you to place XML on a queue for the Siebel MSMQ listener to pick up or retrieve XML from a queue to which a Siebel Workflow, using the EAI MSMQ Transport BS, posts.


There’s more to it than that, though, and the following new features are now available:

  • XML can be posted and retrieved as either plain text or serialised to an XML object
  • XML can be retrieved from a queue or its journal, allowing you to retrieve audit history from your MSMQ queues
  • XML can now be validated against an XSD, allowing you to verify XML before sending it and on receipt
  • The Tools will automatically detect if you have MSMQ enabled on your machine and automatically determine which Private and Public queues are available

The updated tool is now available to buy (yes, buy!) on The Siebel Store, along with a separate option to buy and re-use the C# Source Code.

Siebel and dotMailer – Integration Wrapper

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:

System Preferences


  • Central, configurable parameters to support access and authentication

Workflow Processes


  • 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

Integration Objects


  • Simplified but extensible IOs supporting query and update of Contacts and Campaigns, including history and responses

Data Maps


  • Hierarchical data maps providing standard mappings from dotMailer constructs to Contact and Campaign IOs and vice versa

Business Service


  • Simple, well documented and structured eScript business service providing supporting services in a single, re-usable and customisable form

UI Elements


  • 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!

[poll id=”4″]

Thanks for reading!

Using Wireshark to trace EAI messaging

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

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