Using a Single Endpoint for a Workflow. What is a Workflow?

Mar 30, 2010 at 4:03 PM
There has been group discussion, and agreement, that a trading partner should be using a single endpoint to receive all messages for an entire workflow. The question now is what is a workflow and how granular should a workflow be? DDS proposes a workflow is an entire business process. An example of a workflow is the 'RFP - Proposal - IO' business process. There shouldn't be a workflow for each document type, such as the RFP, Proposal and IO all being separate workflows. Please post other points of view for discussion. Regards, Sandy
Mar 30, 2010 at 9:26 PM

So I have a question – does this, practically speaking, mean that a publisher or agency need to build a “universal catch-all” webservice that then takes a look at which document has been received, and then route it to a specific system within the publisher/agency system family? So for instance, if a company uses Salesforce to track RFPs but uses DoubleClick Sales Manager for Proposal building and receipt of IOs? And if an Agency uses a workflow system to receive Proposals and a financial system to receive Invoices (as the invoice standards are built in the future)

Thanks,

Jeremy

Jeremy Fain
Vice President of Industry Services
INTERACTIVE ADVERTISING BUREAU

116 East 27th Street, 7th Floor, New York, New York 10016
direct: 212 380 4724 / eFax: 212 214 0336 / cell: 646 456 4385

Mar 31, 2010 at 1:24 PM

Jeremy,

If  RFP, Proposal, IO were a workflow as Sandy defined a catch all would be needed.   This is important because an IO is a response to a  Proposal which is a response to an RFP implying some consistency of rules and data.  If there is no catch all on the publisher side then the process may be faced with different rules, codes, etc for documents that are supposed to be closely related.   For example if the proposal and IO may come from different systems it does not make sense to say the IO should mirror the proposal.    Also at some point information is going to have to move between those systems either manual or electronically - a catch all with internal facing processes might facilitate moving the data electronically between systems.    As an example DDS is planning to send a system generated token in the RFP that is needed on the Proposal.  The token is designed to be part of eBusiness and not user friendly for typing.

The invoice process is communicating the actual run and billing information so we would expect that to be a separate workflow. 

Univision was going to provide some thoughts on having an endpoint per document so that the group could discuss the merits of both approaches.

--John

Mar 31, 2010 at 2:56 PM

Granted that it is easier to do it this way, I still do not see the necessity to require a single end point. If a company wants to use more than one, or has to use more than one, data that is sent and needs to be sent back, etc, should be a functional requirement of the messaging architecture and XML schemas and any system that plugs into the translation layers will be required to get the data captures, integrations, and sends right. I guess I have always seen the E-business project as a translation layer, not an actual system integration. The system integration happens behind the translation layer.

Jeremy Fain
Vice President of Industry Services
INTERACTIVE ADVERTISING BUREAU

116 East 27th Street, 7th Floor, New York, New York 10016
direct: 212 380 4724 / eFax: 212 214 0336 / cell: 646 456 4385