centralization vs. fragmentation

Dart, Jocelyn jocelyn.dart at sap.com
Tue Jun 27 19:55:25 EDT 2000


Hi Mark, Will look forward to seeing you.
Regarding XML, the 4.6c parts concentrate on sending the XML - you
still need to create the contents of the XML first, 4.6C does add
a standard WfMC approved wrapper.  It doesn't use the Business Connector
but sends it directly.
Without 4.6c - Business Connector can be set up to forward IDocs as XML so
the easiest thing would be to call something which generates the Idoc and
posts it.  Unfortunately I'm not much of an ALE/EDI bod so I only have a
very sketchy idea of what's involved in doing that but it's been around for
so long it can't be that difficult.  I know there is a standard RFC for
sending
the idoc out but can't recall the exact name - any ALE bod would probably
know
it off the top of their head.
Business Connector and Workflow are really separate tools but of course you
can
control IDocs to a certain extent using workflow.
Hope that helps.
Regards, Jocelyn.
 
-----Original Message-----
From: Mark Huffman [mailto:m.r.huffman at worldnet.att.net]
Sent: Tuesday, 27 June 2000 6:19 AM
To: SAP-WUG at MITVMA.MIT.EDU
Subject: Re: centralization vs. fragmentation
 
 
Hi Jocelyn,
 
Sorry that I missed one of your rare visits to these shores - but I
should be back in Australia for Chrissie, so maybe we can catch up then.
 
I've been reading about the Business Connector and generating XML docs
from BAPIs/IDOCs etc as the cure to all of our ills.
 
In your experience, do the Business Connector and Workflow fit together
to make a more complete solution? I guess what I'm asking is: What is
the effort needed to generate XML docs from a workitem?
 
Best Wishes,
 
Mark
 
 
Dart, Jocelyn wrote:
>
> Hi Mark,
> I'm glad I'm not the only one who feels that history is repeating itself.
>
> *#@&! Irritating isn't it?
>
> I'm amazed at how many people seem to forget all the hard-learned lessons
of
> the past
> as soon as the phrase "e-commerce" comes up.  Funnily enough, little
things
> like project
> planning and ROI, for instance, do still apply.
>
> Very VERY frustrating to see people try to implement quick and dirty
> e-commerce
> solutions which have a snazzy facade but little or no thought has been
given
> to how
> the business process is going to work behind all of this. End result -
loss
> of face and
> loss of user buy-in as it becomes evident that the process is missing
behind
> the facade.
>
> Too much "got to be on the 'net" panic out there.  Certainly we have to
move
> quickly but
> that's no excuse for not thinking through the business process.  It
doesn't
> matter what or
> how many e-commerce applications you put out on your website - if the
> process doesn't work
> it's going to become evident to your users very quickly.  If anything
> e-commerce requires
> greater attention to slick streamlined business processes with attentive
> problem resolution
> - e-commerce users expect speed, don't have a lot of patience and have no
> reason to be loyal
> to a site that gives them grief.
>
> At least these days we have workflow - and it's relatively straight
forward
> to hook it
> behind your e-commerce application.  My two favourite methods at the
moment
> would be
> 1) Using the ITS and the generated WWW transactions to kick of the
workflow
> or execute the workitem
> 2) Have the e-commerce application call an RFC to raise the event
>
> Just saw webflow at the Las Vegas TechEd - looks promising although there
> are still some
> security issues to be resolved in more depth.  Bad news is you need R/3
4.6C
> to run it.
> I guess in the meantime we can simulate cross-corporation flows by adding
> steps to
> trigger RFC calls or XML doc sends to other systems.
>
> The other good news is that there are more and more workflow solutions
> coming out of Walldorf
> - nearly all the new e-commerce solutions involve well-defined
> pre-configured workflows at some point.
> Lots more samples and examples for us to build on.  Also the condition
> editor which lets you
> basically do simple check function modules without programming is useful.
>
> Would recommend people also have a look at the new workflow miniapp which
> sucks the workitems from
> multiple systems into the one web inbox - very interesting!
>
> Regards, Jocelyn.
>
> -----Original Message-----
>> From: Mark Huffman [mailto:m.r.huffman at worldnet.att.net]
> Sent: Tuesday, 13 June 2000 2:08 PM
> To: SAP-WUG at MITVMA.MIT.EDU
> Subject: centralization vs. fragmentation
>
> I'm not claiming any great insight here, but over a quiet beer this past
> weekend, was reflecting on the state of the IT industry and in
> particular some of the large organizations that I consult with.
>
> For those of us who were in IT before SAP R/3, the eighties and early
> nienties was a time of decentralization, with every department wanting
> their own database, standalone expert systems etc.
>
> Then SAP came along with the central database repository concept - I
> remember when I took my first course, the teacher was actually kind of
> sheepish about discussing the architecture as it sounded so mainframish.
>
> For awhile that architecture swept all before it and all sorts of
> systems died only to have their data sucked into some module of SAP. For
> workflow the name of the biggest game was implementing cross-module
> processes within SAP.
>
> But now it seems that the centralization tide has crested and we are
> back to decentralization or even fragmentation. Every deparment wants
> their own customer database and business rule set (deja vu?) with the
> Internet spinning off all sorts of CRM/SCP systems and other acronyms.
>
> Now the SAP teams are being accused of reacting too slowly to change
> requests and for workflow the biggest game apparently is webflow or for
> survival at least backending to a hot new Internet project that just got
> budget.
>
> Any comments? Would be nice to get a good systems debate going again
> rather than just answering the same old questions from consultants who
> can't be bothered calling up their online help.
 


More information about the SAP-WUG mailing list