Write an InfoProvider

Warning: this tutorial is definitively out of date !! Refactoring is in progress …

An InfoProvider is a special orchestration of Web Services inside jSeduite. This orchestration collects all expected informations from the jSeduite services pool, and then return it to the client in a standardized way.

Inside a jSeduite bundle, the InfoProvider is the keystone of the information broadcasting process. Each bundle defines its own InfoProvider, as the broadcasting process is different for each targeted academic institution.

This page is a cookbook to make your life easier when you want to define your own InfoProvider (and so, your own jSeduite bundle). Follow the guidelines and build your own information broadcasting system in a really short time !

Retrieving the Skeleton

The InfoProvider process follows a well-known pattern. We implement this pattern as a BPEL process in the InfoProviderSkel project.

This project is architectured as the following:

The BPEL process skeleton also defines the following variables:

To retrieve the skeleton, copy/paste the InfoProviderSkel Process Files content. Do not forget to retrieve the catalog.xml file content (a premature end of file exception will be throw if you've forgot to copy it).

Skeleton Namespace Customization

In order to avoid namespace conflicts and other XML stuff, you'll need to customize the InfoProvider.* file to define your own process.

If you skip this step, you'll define an Infoprovider using the skel namespace (by the way, it's not a good idea to skip this step …)

If your process validate with these two warnings, you're done with the namespace customization !

Source of Informations

Import WSDL contract

First of all, and even if it sounds like a good idea, you must NEVER used the remote WSDL importation mechanism. It create a (bloody) mess inside the Sources folders, and you'll loose your marbles in a very short time. Always use the local WSDL importation mechanism.

If you've made a mistake and want to delete those file, you'll have to also delete entries in the catalog.xml files as the refactoring process in Netbeans 6.5 doesn't handle it properly.

Customizing the data model

You need to enhance the InfoProvider.xsd data model to handle properly the new source of information:

BPEL global variable

We need to add a global variable in the BPEL Process InfoProvider.bpel to collect all informations from this new source:

<variable name="feed_reader_result" type="ns0:FeedContentSet"/>

Enhancing the call database

If the source of information use input parameters, you'll have to enrich the database with the adequate call informations.

Example: We consider here that we're adding the CachedFeedReader source. The user with login hall subscribes to this source, and expects to retrieve the content of two feeds (TV5_une & Antibes_tout) with a validity period of 30 minutes.

INSERT INTO `sources` VALUES (1, 'CachedFeedReader', 'read');
INSERT INTO `preferences` VALUES (1, 'hall', 1);
INSERT INTO `messages` VALUES (NULL, 1, 1, 'validity', '30');
INSERT INTO `messages` VALUES (NULL, 1, 1, 'name', 'TV5_une');
INSERT INTO `messages` VALUES (NULL, 1, 2, 'validity', '30');
INSERT INTO `messages` VALUES (NULL, 1, 2, 'name', 'Antibes_tout');

Building the invocation pattern

Take a look at the commented first scope (named SourceName) inside the InfoProvider.bpel skeleton code. It implements the pattern of information retrieval for a given source.

Do not hesitate to look the source code of existing providers ( like InfoProviderEpu, …) and inspire your development from those validated process.

Adding information to final result

Take a look at the second commented scope (named SourceName_Feed). This code will feed the global result with the source ones.

Source Policies