I'm not sure I understand the whole scenario, but it might be helpful if you look into using "events" instead of flags. You insert a 'wait-for-event" step in one place and insert a "raise-event" step in another place. This way they can communicate with each other.
Hello,
Just create the container element in the subworkflow. Or have I misunderstood something? If it isn't an actual subworkflow then use one.
regards
Rick Bakker / hanabi technology
Hi Dominik,
This means i need an element that is automatically created for each line of the multiline element in the block-> parallel processing.
Instead of try this in workflow template, create a method and pass the values at each time.
In the method you can append those values to the ,multiline container. Finally just bind the multiline container to workflow container.
Thanks,
Viji.
I'm not sure, if i understand your suggestion correct.
You suggest, i should append the decision (the flag for the loop) to the multiline container. This means i must have a dynamical created element for each line and that is my problem. I COULD create an attribute to the BOR-Object i use for the multiline element, but i don't wan't to. This is not a really clean an nice way. The used object has so far many attributes and this scenario is not the only one. Exact the same is used in other workflows a colleague built. But i don't like the way he built his workflows ("normal" subworkflows not block). And so, the attribute to the object could be misunderstood/bewildering.
This is the screenshot of the graphical design. If you need it more detailed please tell me, then i try to make screenshots of every task and try to put it together.
@Abdullah Azzouni: An event doesn't help, because i want to stay in the loop. Perhaps the loop ist used 2-3 times because the main task (decision) can't be closed because of the lack of information that can be asked with the task in the loop.
@Rick Bakker: I could use a subworkflow instead of a block. With a subworkflow my problem would be solved because with every subworkflow the element for the flag is created seperatly for every line of the multiline element.
But then i have another problem. If i have to delete one of the subworkflows in a runing workflow, the complete workflow is corrupted because it waits for the one (or more) logical deleted subworkflows that will never bring an answer.
At the moment, its the same with a block. If you logical delete one of the dynamical created block-subworkflows (for one line of the multiline element) the complete workflow is corrupted, too.
BUT there is a note(971610), that this will get possible. The note is not compatible to the SAP Release we use, but it opened a new note and hope, that i get a correction i can load into our system.
And we have often the situation, that users tell us, one of the positions is not necessary to work on what means, that the subworkflow (multiline element of the block) is unnessecary. I could manually close the workitem, but probably there a background tasks that will start than. But they mustn't start. So i need to logical delete the complete block.
Back to my question:
With the problem of logical deleting normal subworkflows i need to use a block because with the note (i hope so) this will be possible without corrupting the whole workflow.
But i can only use a block, if i am able to create a flag to stay in the loop that is in the block. In another workflow i had the same problem (and used there a normal subworkflow). I tried to create an element in the local container of the block but this element was not dynamical created with each line of the multiline element. It was created once like i had created it in the main workflow. And so, it was only one element for all lines. This means only the last action to this flag was saved.
Perhaps i created the element wrong ore set some parameters wrong but it didn't work for me last time.
I was surprised because i thought if i create a block with "ParForEach" every element in the local container of the block is created as often as many lines i have but this wasn't so.
I hope you can get now my problem.
Hi,
In perforeach there a cinatiner element automatically created with name _*_LINE . It is created for each block. Try to use it pass it to local container.
Hi,
i know, that in each block an element with *_line is created. This is the element for every single line in the multiline element. But i can't/don't want to use this line element because my multiline element is typed as a BOR-Object like bus2032. I would have to create an attribute to the object and this is not really clean as mentioned in the reply to @vijay kumar.
I want to create a single element type flag in the block in addition to every line that i can use for the loop.
Hello,
I don't really get why you can't use a sub-workflow (corrupted??) but if you want multiple variables then perhaps you could make a multiline container element of type XFELD.
regards
Rick Bakker / hanabi technology
Hi,
i don't want to use a sub-workflow because often we get a call from a user how tells as, that they don't need the subworkflow for i.e. position 2000. But the others are needed. So i have to logical delete the subworkflow for this position. But when i do this, the whole workflow is corrupt. It can't be used any more, because the main workflow waits for all sub-workflows to be completed. But the sub-workflow i did logical delete will never be completed in the way, the main workflow waits for it. So it waits and waits and waits.
At the moment, it's the same with a block. If you delete one of the dynamical created lines of the block, the main workflow is corrupted. But there is a note, that will fix this problem, so i can logical delete one of the lines (a position i don't need) and the other position can be completed normaly and the main workflow is not corrupted. This note doesn't work at the moment for our system, but i opened a new OSS-Ticket and hope, SAP can change this, so we can use it for our release.
I do use a multiline variable now, but this is for the positions. So i need another multiline variable for the flags. For each line of the position element, one line in the multiline variable for the flag.
With a sub-workflow created with parforeach this would be possible, because the flag is created separatly for each subworkflow (each line) but then i habe the problem with logical delete ...
Hello,
What if you manually complete the sub-workflow instead of logically deleting it?
(Not that I think it's a good idea, you having to manually intervene)
regards
Rick Bakker / hanabi technology
Hi,
you cannot manually complete the sub-workflow/block, only tasks. And if i manually complete a task, a background task afterwards may be executed, also i don't want it. Not in this case, but in others.
I have this problem not only in this workflow but i used it for example. I want a general solution for this problem.
Hello,
"you cannot manually complete the sub-workflow/block"
I've done that for sub-workflows.
regards
Rick Bakker / hanabi technology
Your right. I can manually complete the sub-workflow, no other tasks in the sub-workflow are executed and the main workflow is not corrupt.
I'm sorry. Didn't know this by now. Also not my colleague. I wonder why. I always thought we had tested this.
But is there a hitch, except that the sub-workflow task is completed and not logical deleted? The individual tasks of the sub-workflow are logical deleted. This would be correct.
Nevertheless in my opinion a block would be more handsome. For me a block is better to handle. I can get the whole workflow better with a block. Every task is in one workflow and not in many different.Especially when i have only one or two tasks in the sub-workflow.
Well, I don't know if you only must create the workflow and that's it.
I have to administrate my workflows in the productiv system and therefore i try to built them as good as possible, to have less work with administration.
But it's nothing new that most developers create a workflow/program anywise, and the main focus is, that it's running. Never mind, what the future brings ...
Hello,
I don't like subworkflows either but it has nothing to do with ease of administration. In fact, it often makes it easier having subworkflows.
Anyway, what about my previous suggestion of creating a multiline container element at workflow level and using that for your flag variables in your block?
regards
Rick Bakker / hanabi technology
I already have an multiline element for the block. It's the BO object with the positions.
So i can't create another one.
And yes, in some cases a subworkflow might be better but i had some workflows where i had only one task in the block/subworkflow and then i like the block more than the subworkflow.
Hello,
"I already have an multiline element for the block. It's the BO object with the positions. So i can't create another one."
Sure you can. At the workflow level.
regards
Rick Bakker / hanabi technology
Hi,
You are right. But you pass the BO OBJECT reference like that way &bus2032[&_bus2032_LINE&]& at the time of binding.
Hi,
I am talking you want caontainer flag variable for every dynamic created lines. I am showing if you have suppose multiline container element bus2032. Now you want to get each bus2032 in each line. Then you can pick/bind it using following expression &bus2032[&_bus2032_LINE&]& in each processing line
Hi,
i know that i must use the BO-Object as multiline object and that i can pick/bind every single line as &object[&_object_line&]&.
This is my main data in the block.
BUT i need another (multiline) element in the block to set the flag that i want to use for the loop.
When i create a normal subworkflow and start it also with the BO-Object as parforeach and use the "line" element i have the same as i start a block with parforeach.
BUT when i create in the normal subworkflow an element "flag" this flag is created for every line of the object, because for every line is a new subworkflow is created. But with the normal subworkflow i have the problem with logical deleting.
Because of this, i want to use the block.
For every line in the multiline element a new block is created (like in the subworkflow). (Hopefully) with the note mentioned above corrected for our release (702) is can logical delete one of the blocks create for every line.
BUT when i create a normal element in the local container of the block, this element is not created for every line of the object as i thought it would be. When i tried this in another workflow, it was created only once for the hole block, that means, once for all of the lines. So the element was used in every block the same. If you change it in one block (one line of the multiline element) it was also changed in all the other blocks (lines). So it is not a seperated element for every position but this is what i need.
Perhaps it doesn't work like i want to, but perhaps i made some settings wrong and it will work like i need it when i set them the correct way.
Hi,
Try like this way if it is possible to set second multiline element.
First you declare a WAIT EVENT USING WORKFLOW inside the block.
Then create a step with BO method where you pass Line no and Flag mutiline element as input. And it will retrun the multiline element which is set with the flag.
Then you add the step Event Creator which will triger event for wait event.
What happen every block will wait for the event. As you are using WAIT EVENT USING WORKFLOW. If you first trigger the event only one block's wait event will accept the event. Then you set your multiline element with that line. After that you trigger event again, Then it will call for second block wait event. Like that way you set all the line of multinline event.
Then do your remaining processing.
Try with this technique.
Hi,
Did you try this in upper mention way to populate second multiline cotainer
Sry, i didn't try it, because i couldn't understand what you suggested. A colleague of mine also read it but didn't get what you mean.
Since you are not convinced with the different suggestions provided above, I have a crazy suggestion that I think will work. I wouldn't implement it myself, but you could evaluate whether it (or a similar one) will work for you. Why not create a virtual parameter in your BO. This virtual parameter returns a value from a custom db table (or any persistent storage media) that is linked to your BO. Then, create a "set_value" and "get_value" methods in the BO. In your workflow template, you can use these two methods to set and get the value where you need it!
I had a similar idea, but i don't like it. As you said, i also wouldn't implement it. But thank you.
I still don't understand why you cannot use the local container element. The local container element data is not for the entire block but for each instance of the block that is created. every block instance that is created will have its own local container element value. otherwise there is no meaning for local container at all.
I thought the same, but it didn't work this way when i tried it.
The local container of the block was only created once, not for every instance. Only the multiline element was created separately for every instance.
Because of this, i opened this thread. Otherwise it wouldn't be necessary.
Dear,
I have created many workflows using blocks parallel approval with lot many local container elements in it. Thats why I replied to your query. As its working for me, I think it should work for you too.
Well, i could also create elements in the local container of the block. But these elements weren't created seperatly for every instance of the block. When i tried this, the elements were only created once for all instances of the block.
Make sure in the local container element for the flag is not greyed out when you create the element. if its greyed out, the element will act as a global container element. if all the elements which you are creating inside are greyed out by default, the block is corrupted so you need to delete the block and create a new one.
Hi,
May be you should try in other way like, if you have chosen a block step and that too PAR FOR EACH then you should treat them each individual set of steps generated by the workflow for each entry in the multi-line container element, in this case each independent local container is unique from other local container,
What you can try to do is once he approves then try to get all the dependent work items under the block step this will give all the work items that are created under block step, then try to read the container of each work item to get what ever value that you are expecting.
I hope this would help you...
Regards
Pavan
