Architecture question

I am a newbie to Notification service and I need your help to determine what's the best way to handle my situation. First of all, I need to determine if Notification service is the right approach.

We have a ASP.NET application that creates purchase orders to various suppliers. Few suppliers are fine with just "Email notifications". But few of them need the PO XML sent to their FTP site. We might have future suppliers and they may want a different mode of communication.

Here's my solution to this problem and I need your expert advice

Step 1: Create an event schema that captures all the item details in a PO.

Question: What is the best way to implement hierarchies [PO Header, PO Line item]? I am thinking of adding all the head fields to the schema for every line item.

Step 2: My delivery channels will be "Email" or "FTP" [custom delivery channel]. Some suppliers will subscibe using email channel, and some FTP

Question: Is there a way I can use the "File" channel to download a PO [with unique file names] and develop an external program to just FTP the file to the supplier?

Step 3: When a new PO is created, I will call my event provider to submit the event [I might use the out of the box Stored procedures]. Depending upon the Subscriber's delivery channel [protocol], the appropriate delivery channel will be chosen.

Any thoughts/help or suggesstions?

I think the easiest hierarchy is a flat structure (one root node, one level of child elements).

As for the File channel, you cannot use the built-in File delivery protocol in this way. It writes results to a single file, and is primarily intended for testing. You could write a custom File delivery protocol that produces unique file names and performs other processing.

|||As Diane mentioned, SSNS really thinks in terms of notifying people of somewhat flat data structures. If you need to have parent-child detail information, what I typically do is create a custom content formatter. In there I make a connection to the database that stores the additional information and query the supplemental information. I then format it along with the normal SSNS notification information (parent stuff) and return it to the distributor.

To write to separate files for each notification, you'll need to create a custom delivery protocol. You can base the file name off the subscriber and perhaps a datetime to make sure it's unique.

If you're parent-detail information is in a database, it's probably easiest to use the SQL Server Event Provider, but you can use the SSNS stored procedures to submit the event if you'd rather.

HTH...

Joe|||

Thanks for your replies.

Joe,

How about if I just pass the "PO" number to the "Custom Delivery Channel" that queries the database for a given PO and then, creates an XML file? Do you think that will make it easier?

Regards

|||Hi Ragas -

That's typically the tact that I take.

In your example (and I'm assuming a bit here since I don't know the details), I'd probably have the event provider submit a few vital pieces of info to SSNS; at a minimum the PO number, but if you have other pieces of information readily accessible then I'd submit that too (especially if it'll save one or more db calls from within the custom component). In your case, you may also want to submit the CustomerId, too.

I typically gather the other information in the content formatter rather than the delivery channel.

HTH...

Joe|||

I'm a NS newbie, creating my first NS app which indeed does notifications based on orders with line items (parent/child records).

However, I don't feel architecturally, pulling outside data (line items) is appropriate for either the content formatter or the delivery channel. IMHO, they should be responsible for (and only for) content formatting and delivery, respectively.

My intended solution is to flatten the order details much earlier in the process - in my custom event provider (which is a component responsible for data!). I need a custom event provider for other reasons (data coming from a web service), but this approach to handling parent/child records shouldn't require a cutom provider - I presume it'd work (even easier) with the SQL provider though I admit I haven't used that provider.

The trick is simple: I define the event class (and notification class) to contain the fields for the parent Order, and my order details (order line items) go into a single xml type column of this event class.

Simplified example snippet:

<EventClass>

<EventClassName>OrderData</EventClassName>

<Schema>

<Field>

<FieldName>CustomerName</FieldName>

<FieldType>nvarchar(128)</FieldType>

</Field>

<Field>

<FieldName>OrderDetails</FieldName>

<FieldType>xml</FieldType>

</Field>

Fill in OrderDetails with the aggregate line items and voila, a single "flat" event record with all the data needed for the notification. If all your source data is available in SQL, I imagine you could also do this flattening in the subscription action - pulling order line items out (as XML) based on the parent order ID and pushing them into the notifications view?

Note how this allows me to continue using the built-in XSLT formatter because the entire stream of event data is still just XML when it hits the XSLT. For line items that just an xsl for-each instruction loop to format the line items from the OrderDetails.

Note: to use this technique you need to turn off escaping in your ADF file so that XML flows through to the XSLT file during formatting:

<ContentFormatter>

<ClassName>XsltFormatter</ClassName>

<Arguments>

<Argument>

<Name>XsltBaseDirectoryPath</Name>

<Value>C:\SQL Notification Services\Orders\</Value>

</Argument>

<Argument>

<Name>XsltFileName</Name>

<Value>OrderSubmitted.xslt</Value>

</Argument>

<!-- we disable escaping so that our XML column (orderdetails) stays as

XML when being passed to the XSLT file for processing. The default is to

escape the embedded XML (e.g. "bar&gt;a bar&lt;/bar&gt;&lt" for "<bar>a bar</bar>" -->

<Argument>

<Name>DisableEscaping</Name>

<Value>true</Value>

</Argument>

</Arguments>

</ContentFormatter>

sql