Re: Re: SCP Workflow question
Kjetil Kilhavn
list.sap-wug at vettug.no
Wed May 9 22:59:09 EDT 2018
Ahhh, finally dawned on me that SCP is not just any old acronym - you
are working on a SAP Cloud Platform workflow solution.
Sad to say I don't really know anything about that yet - so my input may
be completely useless. (Or should I be happy to say I don't know
anything about SCP Workflow yet? Hmmm...)
Den 09. mai 2018 12:13, skreiv Andy Curtis:
> Maybe I am doing a poor job of explaining because we do have a team of
> experienced mobile people.
>
> We originally said, 'when user presses 'submit' there should be 2
> things happen, the 'request' should be saved and Wf should be
> triggered. They read this as 2 client side actions (1 to send screen
> data to the server, the second to trigger Wf) and were concerned what
> would happen if the first action succeeded and the second failed. The
> answer to that is to have 1 server side service to receive the screen
> data, create a database record and trigger Wf). But the pushback came
> that if there was 1 client side action to trigger Wf (server side)
> passing the screen data to the Context, then Wf could create the
> database record as the first step.
>
> Thats where my karma is suffering. I believe it is 'right/correct' to
> have a server side service receive the screen data, create a 'request'
> on a database and then trigger Wf. Replacing the server side service
> to receive the screendata and trigger Wf, I think is fundamentally
> wrong because I have never created a Wf that did not have an business
> object/Class instance when it started.
>
> Thoughts?
>
> Andy
>
>
> On Wed, May 9, 2018 at 10:11 AM, <sap-wug-request at mit.edu
> <mailto:sap-wug-request at mit.edu>> wrote:
>
> Send SAP-WUG mailing list submissions to
> sap-wug at mit.edu <mailto:sap-wug at mit.edu>
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mailman.mit.edu/mailman/listinfo/sap-wug
> <http://mailman.mit.edu/mailman/listinfo/sap-wug>
> or, via email, send a message with subject or body 'help' to
> sap-wug-request at mit.edu <mailto:sap-wug-request at mit.edu>
>
> You can reach the person managing the list at
> sap-wug-owner at mit.edu <mailto:sap-wug-owner at mit.edu>
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of SAP-WUG digest..."
>
> Today's Topics:
>
> 1. Re: ?SCP Workflow question (Dart, Jocelyn)
>
>
> ---------- Forwarded message ----------
> From: "Dart, Jocelyn" <jocelyn.dart at sap.com
> <mailto:jocelyn.dart at sap.com>>
> To: "SAP Workflow Users' Group" <sap-wug at mit.edu
> <mailto:sap-wug at mit.edu>>
> Cc:
> Bcc:
> Date: Wed, 9 May 2018 09:11:13 +0000
> Subject:
>
> Re: SCP Workflow question
> Hi Andy
> Ok this sounds like the usual non workflow developer mistake of
> thinking workflow is somehow another pseudo database. With this
> approach if you lose comms you have an orphaned workflow.... which
> surely would be much harder to clean up than a single database
> entry wherever it is held.
>
> Do they have anyone who has actually done offline mobile scenarios
> before advising them?
>
> To me - and granted I am not an expert in this - it sounds more
> like what you need is a staging table in the cloud database for
> the initial request. Then if all details are received that
> becomes your draft business object trigger for the workflow which
> then completes the process including identifying if the entry is a
> duplicate or receiving out of order or whatever & if all is well
> then updating the real backend database & then ends with cleaning
> up the draft/staging entry.
>
> That way you know if there is anything outstanding or blocked by
> checking the staging table contents
>
> Just a suggestion... again really they need to involve someone
> with offline mobile experience
> Rgds
> Jocelyn
>
> Sent from my iPhone with many apologies for the spelling, grammar
> and any other deficiencies
>
> On 9 May 2018, at 6:43 pm, Andy Curtis <abcurtis at gmail.com
> <mailto:abcurtis at gmail.com>> wrote:
>
>> Thanks WUG'ers
>>
>> I'll add some 'colour' to my scenario. We have a UI5 screen to
>> create a 'request' this screen can be delivered to a user on any
>> device, including mobile phones where comms could be patchy, so
>> loss of comms is a feature that the 'techs' are concerned about.
>> So the proposal from them is to have a single comm from the UI5
>> when the 'request' data is entered. So, data coming from a
>> screen on a mobile, arrives at the server and something needs to
>> take it and create a 'request' in a database. My opinion is
>> there should be a Service to receive the comms and create the
>> 'request' in the database, assigning a number to it and then
>> triggering Wf passing the 'request' that has been saved on a
>> database.
>>
>> Their suggestion is, when the data arrives at the server it
>> triggers Wf immediately (before the 'request' is created on the
>> database) and the first step in the Wf is to create the 'request'
>> get back the 'request' nbr and then continue through the approval
>> process. This would be the first time I have ever started a Wf
>> without an instance of the object, (I don't think I could trigger
>> a Classic Wf without an object instance) and it just does not
>> feel right to me. Hence my question to the community to find out
>> if others thought it was good practice to start a Wf without an
>> object instance and have Wf create it.
>>
>>
>> @Kjetil, in a create vendor account process, would the first
>> step be a user in XK01 creating a Vendor account? When saving
>> the transaction it creates a vendor record and triggers Wf to
>> start the process. The vendor nbr would exist before Wf was
>> triggered and an instance of the vendor object would exist. Or
>> maybe you have a Form and you want to start a Wf to create a
>> vendor master
>>
>> @Mark, I started to think SAP Cloud was the new R/3 and prepared
>> to catch a new wave,
>>
>>
>>
>>
>> Andy Curtis
>>
>>
>> On Wed, May 9, 2018 at 12:55 AM, <sap-wug-request at mit.edu
>> <mailto:sap-wug-request at mit.edu>> wrote:
>>
>> Send SAP-WUG mailing list submissions to
>> sap-wug at mit.edu <mailto:sap-wug at mit.edu>
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> http://mailman.mit.edu/mailman/listinfo/sap-wug
>> <http://mailman.mit.edu/mailman/listinfo/sap-wug>
>> or, via email, send a message with subject or body 'help' to
>> sap-wug-request at mit.edu <mailto:sap-wug-request at mit.edu>
>>
>> You can reach the person managing the list at
>> sap-wug-owner at mit.edu <mailto:sap-wug-owner at mit.edu>
>>
>> When replying, please edit your Subject line so it is more
>> specific
>> than "Re: Contents of SAP-WUG digest..."
>>
>> Today's Topics:
>>
>> 1. SCP Workflow question (Andy Curtis)
>> 2. Re: SCP Workflow question (Kjetil Kilhavn)
>> 3. Re: SCP Workflow question (Mark Pyc)
>>
>>
>> ---------- Forwarded message ----------
>> From: Andy Curtis <abcurtis at gmail.com
>> <mailto:abcurtis at gmail.com>>
>> To: "SAP Workflow Users' Group" <sap-wug at mit.edu
>> <mailto:sap-wug at mit.edu>>
>> Cc:
>> Bcc:
>> Date: Tue, 8 May 2018 18:08:44 +0100
>> Subject:
>>
>> SCP Workflow question
>> WUG'ers :) (longtime no see)
>>
>> I am graduating to SCP Workflow and have a question, I wonder
>> if anyone can help me out.
>>
>> I have always built Classic Workflows triggered after an
>> object has been created in a database, or SAP always saves
>> the object and then sends the Wf triggering event. I would
>> say thats best practice and it also fits with my other
>> narrative about keeping process and application logic separate.
>>
>> In SCP it is possible to trigger a SCP Workflow without an
>> Object, but is that a good idea? The thought it to trigger
>> SCP Wf and have a step that calls a task to create the
>> object, so the Wf is basically generic to start with, then
>> becomes instantiated after the first step. Would anyone else
>> think this is a good idea? I don't, I think a Wf should have
>> an object before being started but I am having a hard time
>> arguing the case, so really looking for other informed opinion.
>>
>> Anyone got one?
>>
>>
>> Andy Curtis
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: Kjetil Kilhavn <list.sap-wug at vettug.no
>> <mailto:list.sap-wug at vettug.no>>
>> To: sap-wug at mit.edu <mailto:sap-wug at mit.edu>
>> Cc:
>> Bcc:
>> Date: Tue, 8 May 2018 22:03:13 +0200
>> Subject: Re: SCP Workflow question
>>
>> What is an object? If the workflow is "Create Vendor Account"
>> and takes a bunch of input parameters for the new vendor,
>> then why not let it start before there is an LFA1 record in
>> the database? You have an object, it just isn't complete yet,
>> it is a draft for a vendor record. Sort of like FIPP objects.
>>
>> But the way you describe it it may also be a workflow that
>> doesn't have a clue what is about to happen, so any type of
>> object can be created etc. I suppose it could still be a
>> valid use case, but it's a bit harder to imagine. How would
>> one for instance identify agents for the first step if you
>> don't even know what is going to be created.
>>
>>
>> Den 08. mai 2018 19:08, skreiv Andy Curtis:
>>> WUG'ers :) (longtime no see)
>>>
>>> I am graduating to SCP Workflow and have a question, I
>>> wonder if anyone can help me out.
>>>
>>> I have always built Classic Workflows triggered after an
>>> object has been created in a database, or SAP always saves
>>> the object and then sends the Wf triggering event. I would
>>> say thats best practice and it also fits with my other
>>> narrative about keeping process and application logic separate.
>>>
>>> In SCP it is possible to trigger a SCP Workflow without an
>>> Object, but is that a good idea? The thought it to trigger
>>> SCP Wf and have a step that calls a task to create the
>>> object, so the Wf is basically generic to start with, then
>>> becomes instantiated after the first step. Would anyone
>>> else think this is a good idea? I don't, I think a Wf
>>> should have an object before being started but I am having a
>>> hard time arguing the case, so really looking for other
>>> informed opinion.
>>>
>>> Anyone got one?
>>>
>>>
>>> Andy Curtis
>>>
>>>
>>>
>>> _______________________________________________
>>> SAP-WUG mailing list
>>> SAP-WUG at mit.edu <mailto:SAP-WUG at mit.edu>
>>> http://mailman.mit.edu/mailman/listinfo/sap-wug
>>> <http://mailman.mit.edu/mailman/listinfo/sap-wug>
>>
>> --
>> Kjetil Kilhavn
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: Mark Pyc <mark.pyc at gmail.com <mailto:mark.pyc at gmail.com>>
>> To: "SAP Workflow Users' Group" <sap-wug at mit.edu
>> <mailto:sap-wug at mit.edu>>
>> Cc:
>> Bcc:
>> Date: Wed, 9 May 2018 09:50:14 +1000
>> Subject: Re: SCP Workflow question
>> Agree with Kjetil and agree it's a lot like a FIPP to BKPF or
>> maybe more so like BUS2105 to BUS2012. Thing is LFA1 doesn't
>> have such an obvious 'requested' phase. I've done similar
>> things before but I end up creating a request application
>> which assigns a GUID to the request, and that's the object
>> that the WF operates on. Now you _could_ use the WF instance
>> id as the request number and capture all the data into
>> containers rather than custom tables but, in non-cloud at
>> least, that would seem to me to be a lazy hack that would
>> cost you in the long run - think about reporting and monitoring.
>>
>> The cloud... hmmm don't get me started on the cloud, or least
>> SAPs endeavours in that space... it might seem easier to use
>> the WF as the request DB but again I still think it's lazy. I
>> started typing thinking I might have a different attitude
>> given the cloud but I don't
>>
>> Create a "Vendor Request" application (if you don't want to
>> use MDM requests and WF - not sure of cloud availability) and
>> then build WF with a known instance as you always would.
>>
>> My 2p / 2c / 2 lowest units of your desired currency.
>>
>> Have fun,
>> Mark
>>
>> On 9 May 2018 at 06:03, Kjetil Kilhavn
>> <list.sap-wug at vettug.no <mailto:list.sap-wug at vettug.no>> wrote:
>>
>> What is an object? If the workflow is "Create Vendor
>> Account" and takes a bunch of input parameters for the
>> new vendor, then why not let it start before there is an
>> LFA1 record in the database? You have an object, it just
>> isn't complete yet, it is a draft for a vendor record.
>> Sort of like FIPP objects.
>>
>> But the way you describe it it may also be a workflow
>> that doesn't have a clue what is about to happen, so any
>> type of object can be created etc. I suppose it could
>> still be a valid use case, but it's a bit harder to
>> imagine. How would one for instance identify agents for
>> the first step if you don't even know what is going to be
>> created.
>>
>>
>> Den 08. mai 2018 19:08, skreiv Andy Curtis:
>>> WUG'ers :) (longtime no see)
>>>
>>> I am graduating to SCP Workflow and have a question, I
>>> wonder if anyone can help me out.
>>>
>>> I have always built Classic Workflows triggered after an
>>> object has been created in a database, or SAP always
>>> saves the object and then sends the Wf triggering
>>> event. I would say thats best practice and it also fits
>>> with my other narrative about keeping process and
>>> application logic separate.
>>>
>>> In SCP it is possible to trigger a SCP Workflow without
>>> an Object, but is that a good idea? The thought it to
>>> trigger SCP Wf and have a step that calls a task to
>>> create the object, so the Wf is basically generic to
>>> start with, then becomes instantiated after the first
>>> step. Would anyone else think this is a good idea? I
>>> don't, I think a Wf should have an object before being
>>> started but I am having a hard time arguing the case, so
>>> really looking for other informed opinion.
>>>
>>> Anyone got one?
>>>
>>>
>>> Andy Curtis
>>>
>>>
>>>
>>> _______________________________________________
>>> SAP-WUG mailing list
>>> SAP-WUG at mit.edu <mailto:SAP-WUG at mit.edu>
>>> http://mailman.mit.edu/mailman/listinfo/sap-wug
>>> <http://mailman.mit.edu/mailman/listinfo/sap-wug>
>>
>> --
>> Kjetil Kilhavn
>>
>>
>> _______________________________________________
>> SAP-WUG mailing list
>> SAP-WUG at mit.edu <mailto:SAP-WUG at mit.edu>
>> http://mailman.mit.edu/mailman/listinfo/sap-wug
>> <http://mailman.mit.edu/mailman/listinfo/sap-wug>
>>
>>
>>
>> _______________________________________________
>> SAP-WUG mailing list
>> SAP-WUG at mit.edu <mailto:SAP-WUG at mit.edu>
>> http://mailman.mit.edu/mailman/listinfo/sap-wug
>> <http://mailman.mit.edu/mailman/listinfo/sap-wug>
>>
>>
>> _______________________________________________
>> SAP-WUG mailing list
>> SAP-WUG at mit.edu <mailto:SAP-WUG at mit.edu>
>> http://mailman.mit.edu/mailman/listinfo/sap-wug
>> <http://mailman.mit.edu/mailman/listinfo/sap-wug>
>
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu <mailto:SAP-WUG at mit.edu>
> http://mailman.mit.edu/mailman/listinfo/sap-wug
> <http://mailman.mit.edu/mailman/listinfo/sap-wug>
>
>
>
>
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
--
Kjetil Kilhavn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20180509/eeff6b44/attachment-0001.html
More information about the SAP-WUG
mailing list