Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PDWS: Workflow Templates #154

Open
larshp opened this issue Feb 5, 2016 · 24 comments
Open

PDWS: Workflow Templates #154

larshp opened this issue Feb 5, 2016 · 24 comments
Assignees
Labels
new feature New feature or request serialization Translate between object types and files

Comments

@larshp
Copy link
Member

larshp commented Feb 5, 2016

No description provided.

@larshp larshp added the serialization Translate between object types and files label Feb 5, 2016
@larshp
Copy link
Member Author

larshp commented Feb 5, 2016

from @jani80k
"One hint for PDWS, there is an existing functionality by SAP to export Workflows.
LSWDDF70 Form xml_export."

@christianguenter2
Copy link
Member

christianguenter2 commented Jul 14, 2018

We are really eager to implement this and PDTS. I did several experiments but couldn't figure out how to solve the problem of custom number ranges and internal numbering. E.g. WS9000001 could become WS91000055 in another system. Any idea how to solve this?

@larshp
Copy link
Member Author

larshp commented Jul 14, 2018

how does this work with normal SAP transports?

@christianguenter2
Copy link
Member

christianguenter2 commented Jul 14, 2018

I tried to figure out how it works with normal SAP transports, but didn't come far.

@se38
Copy link
Contributor

se38 commented Sep 26, 2018

Any news on Workflows / Tasks? Could currently need it ;-)
Do you know how it worked in Saplink? https://app.assembla.com/spaces/saplink-plugins/subversion/source/HEAD/trunk/Workflow

@larshp
Copy link
Member Author

larshp commented Sep 26, 2018

dont think so, pull requests welcome :)

@pokrakam
Copy link
Member

pokrakam commented Dec 27, 2018

This should not change the numbers, as it's meant to be landscape-specific per design. I am happy to do this, but not able to assign the issue to me.
Also suggest combining with #153 as it's the same object internally.

@christianguenter2
Copy link
Member

christianguenter2 commented Dec 27, 2018

@pokrakam cool, I did some experiments with PDWS and PDTS maybe this is of any help for you.

To be able to assign an issue to you, I think you need push rights for the abapGit repo.
isaacs/github#100

Maybe @larshp can grant them to you.

@pokrakam
Copy link
Member

pokrakam commented Dec 27, 2018

Cool, thanks I'll take a look.

@larshp
Copy link
Member Author

larshp commented Dec 28, 2018

assigned

@larshp
Copy link
Member Author

larshp commented Feb 27, 2019

@pokrakam any luck/progress?

@pokrakam
Copy link
Member

pokrakam commented Feb 27, 2019

Working on it, a little time-constrained so only getting in the odd couple of hours on a weekend.
Not sure the SAPlink logic that Christian copied from ever worked under SAPlink. Rather than butcher it, I went back to square one and tried to dig into the transport system to replicate that function, but spent many hours working out how to debug it. Seems it's triggered by tp from the OS level and refuses to trigger any breakpoints. Can't work out how to catch it and see what it does. Any ideas?
My next step was to go back to crowbaring the 'right' logic into the WF create module.

@larshp
Copy link
Member Author

larshp commented Feb 27, 2019

see #2444 it is the closest we get to the transport system, implementing a similar approach for workflows might work. But rather use the API if its possible

@pokrakam
Copy link
Member

pokrakam commented Feb 27, 2019

Agree, the issue is that the API imports a WF into a local one, i.e. assigning a number from your local range. Not idempotent, and you can't copy back and forth between systems. Same goes for HR objects which may or may not be transportable (config setting).

A ToC will keep the numbering intact. This is by design in order to be able to copy WF's between systems without conflict (provided each system has a distinct number range, which is set up via a prefix). IMO this is how abapGit should work.
So I can hack the API, or I can figure out what tp does. I tried that option first. The transport system is a very black box :-)

@larshp
Copy link
Member Author

larshp commented Feb 27, 2019

it will break the number ranging? if current number is "1" and we import "2", then SAP standard will determine to use "2".

What is the typical setup if there are multiple development systems in which work flows are created?

perhaps we can somehow choose to import it to a different number and keep the mapping information, it raises some issues on what to show to the user

@pokrakam
Copy link
Member

pokrakam commented Feb 27, 2019

It’s a bit like a namespace + original system concept. A number range with a prefix starting with 9 (customer space) is defined in each dev system. So system A with number 901... won’t conflict with system B using 902... if you transport between them.
Import/Create local -> generate new number in own range.
Transport -> use original number (overwrite and generate new version). This is what we want to do.

Yes it does raise issues if a foreign system uses a conflicting range. But this is the same as importing a same-named class and there are workarounds.

@pokrakam
Copy link
Member

pokrakam commented Jun 5, 2019

Just in case anyone is wondering, I haven't forgotten. Time constrained by projects until the end of June. If anyone wants to work on it before then feel free, else I'll pick it up again in July.

@WillianGruber
Copy link

WillianGruber commented Nov 8, 2019

WF create module

@pokrakam what is this module?

@chrismills
Copy link
Contributor

chrismills commented Nov 11, 2020

Was this previously supported in some form? I've recently updated my ABAPGit version (1.101.0) and when I go to an existing repo it's now advising me that PDTS and PDWS objects not supported and wants to remove the existing .pdws.xml and .pdts.xml files from my repo.

I was having short dumps when i first opened this repository. I found some old classes in a abap git plugins package so not sure if there was some old community unofficial support for these object types?

@pokrakam
Copy link
Member

pokrakam commented Nov 11, 2020

How old was this repo? These were never supported in abapGit AFAIK.

Once upon a time there was some incomplete work in SAPlink to get PDTS/WS working. @christianguenter2 had a go at porting this into abapGit, but on his fork. So the only thing I can think of is if you worked with his clone?

Regardless, your XMLs are unlikely to work. I'd be interested to see some of their contents, it may shed some more light.

@chrismills
Copy link
Contributor

chrismills commented Nov 11, 2020

Hi @pokrakam repo its self not old, created this year, but until recently was using an older abapgit which had the old ZABAPGIT_FULL report name and then updated to the newer ZABAPGIT_STANDALONE more recently as was getting github warnings about the login method and 2FA so needed to update it all.

Looks like in my system we had a dev version of abap git too at some point so in the upgrade i had to delete a lot of Z classes in $ packages that were for abap git as they weren't compatible with new report.

Never tried to restore the WF objects though, but was happily committing them away along with other code. I'll send you some example code via private message on LinkedIn

Cheers

@pokrakam
Copy link
Member

pokrakam commented Nov 11, 2020

Hi @chrismills, the XML was very useful. The key clue was in:
<abapGit version="v1.0.0" serializer="ZCL_ABAPGIT_OBJECT_BY_SOBJ" serializer_version="1.0">
So it was serialised as a standard SOBJ object, I'll look into this a little further.

@pokrakam
Copy link
Member

pokrakam commented Nov 11, 2020

OK it was done using the deprecated SOBJ plugin
https://github.com/abapGit/abapGit-Plugins
You can probably use the plugin if you're importing on the same SAP version as you exported, but generally it's at your own risk. SOBJ is just a 'dumb' transport of the table entries that make up a table-based SAP object, whereas PDTS and PDWS will create all the components of a Task and a WF using SAP's own functions.
Note PDTS is live but still has some minor issues (most notably container element texts are missing) and needs the "Experimental features" switched on. I'm still busy with PDWS.
PS. Needless to say the SOBJ-generated PDTS XML is not compatible with the PDTS serialiser, they are technically completely different objects.

@chrismills
Copy link
Contributor

chrismills commented Nov 12, 2020

Thanks for looking in to that Mike, good to understand how it was working before. I'll steer clear of the SOBJ since it's been deprecated and instead try the experimental for PDTS and keep an eye out on when PDWS is supported too. Thanks for your work on this, appreciated 😃

@mbtools mbtools changed the title PDWS Workflow templates PDWS: Workflow Templates Sep 21, 2022
@mbtools mbtools added the new feature New feature or request label Sep 21, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
new feature New feature or request serialization Translate between object types and files
Development

No branches or pull requests

7 participants