|
Home > Archive > BizTalk Server Orchestration > January 2005 > Reveiving Excel Documents
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Reveiving Excel Documents
|
|
|
| Quite new to BizTalk 2004, so please bear with me...
Our requirement is to process daily excel documents containing several
worksheets of data using BizTalk 2004. We do not have any control over the
documents, so exporting to XML, CSV and other formats is not possible.
We have existing code to convert the documents into XML files, which we are
happy to reuse, but would rather not deploy proprietory software directory
monitoring to kick off the process.
Is there any way to intercept a file within Biztalk immediately after it has
been picked up, prior to any flat-file decoding so that we can convert to XML
using our existing routines, then use the standard XMLReveive pipeline.
It seems unecessary to have to have a secondary process to monitor
directories to pick up these files - would be great to leverage that part of
BT.
Should we be implementing a custom Disassembler or Decode component to do
this? It didn't look to obvious how to do this given my understanding that
they receive a stream as input. A pointer to any documentation on this topic
would be good.
I would assume processing of Office documents in native format is a fairly
common requirement, so I am probably missing something here.
Thanks in advance
Dom
| |
| Matt Milner 2005-01-13, 2:50 am |
| Yes, a custom disassmbler would probably be your best bet. I'd start by
deriving from the XmlDisassembler. In the disassemble method, do your
custom parsing to create hte xml, then call down to hte base class to
disassemble as well. Then the base class' implementation of the GetNext
method do the rest of the work.
Matt
"Dom" <dom@myworld> wrote in message
news:1CFC2001-22C2-4422-B329-6A065A83D42D@microsoft.com...
> Quite new to BizTalk 2004, so please bear with me...
>
> Our requirement is to process daily excel documents containing several
> worksheets of data using BizTalk 2004. We do not have any control over
> the
> documents, so exporting to XML, CSV and other formats is not possible.
>
> We have existing code to convert the documents into XML files, which we
> are
> happy to reuse, but would rather not deploy proprietory software directory
> monitoring to kick off the process.
>
> Is there any way to intercept a file within Biztalk immediately after it
> has
> been picked up, prior to any flat-file decoding so that we can convert to
> XML
> using our existing routines, then use the standard XMLReveive pipeline.
>
> It seems unecessary to have to have a secondary process to monitor
> directories to pick up these files - would be great to leverage that part
> of
> BT.
>
> Should we be implementing a custom Disassembler or Decode component to do
> this? It didn't look to obvious how to do this given my understanding
> that
> they receive a stream as input. A pointer to any documentation on this
> topic
> would be good.
> I would assume processing of Office documents in native format is a fairly
> common requirement, so I am probably missing something here.
>
> Thanks in advance
>
> Dom
>
| |
| Yossi Dahan 2005-01-13, 7:47 am |
| You may also want to look at Itemfield's ContentMaster which has a
disassembler for BizTalk with build it capabilities to convert excel
documents to any format (including, of course, xml), as a disassembler this
will natively sit in your receive pipeline.
more info can be found on http://www.itemfield.com/partners/ms_pf.shtml
Yossi Dahan
"Matt Milner" <matt.milner@m3technologypartners dot com> wrote in message
news:%233PbFiS%23EHA.3616@TK2MSFTNGP11.phx.gbl...
> Yes, a custom disassmbler would probably be your best bet. I'd start by
> deriving from the XmlDisassembler. In the disassemble method, do your
> custom parsing to create hte xml, then call down to hte base class to
> disassemble as well. Then the base class' implementation of the GetNext
> method do the rest of the work.
>
> Matt
>
>
> "Dom" <dom@myworld> wrote in message
> news:1CFC2001-22C2-4422-B329-6A065A83D42D@microsoft.com...
>
>
|
|
|
|
|