cancel
Showing results for 
Search instead for 
Did you mean: 

ARQ: MSMP Workflow version Activation and Existing Requests' Fate???

former_member184114
Active Contributor
0 Kudos

Hi,

Our current Workflow solution is working fine to cater the current business requirements. Now an addition is made to the MSMP workflow to address the "Default" roles. In this regard, routing rule is enabled at Manager level. This is successfully moved to Quality System and I generated the MSMP workflow version in Quality System. After that I tested the scenario and it worked as expected.

Now it is moved to Production system. Currently, there are multiple requests with "Pending" status in Production system. If I activate (generate) the MSMP workflow version, all the existing requests would become "Invalid" and cannot be processed because of MSMP version change!

May I have your valuable inputs to address this issue? I believe, I need to generate the MSMP workflow version to bring "Default" roles functionality in effect. What should be the reasonable solution to:

1. get current requests approved seamlessly?

2. get "Default" roles functionality introduced?

Please advise.

Regards,

Faisal

Accepted Solutions (1)

Accepted Solutions (1)

kevin_tucholke1
Contributor
0 Kudos

If you did not have the Runtime Config check OK checked, the existing workflows will continue as normal in the version that they were created in.

Now, I will guess that Manager stage is the first stage in your path, any requests that are past that whether you allow them to move to the next version or not would not have any issue (as long as you still have role assignment owners on the role)...you should have no issues.

The end users in either case, unless you have something strange in the follow on stages in your path, should not even be aware that something has happened.  They might think its strange if you have let the Role Assignment approvers that you have dealt with these differently going forward after a specific date.

You should be ok to move forward at a good cutoff (end of day) so that if an approver gets a request that is before a certain date, it may contain these default roles and requests created after that date would not.

For the Default Roles functionality, you should be good to insert the master data in NWBC when you need to.  You will only get the default roles for NEW requests that are created after the data has been created.


Hope this helps.

Kevin Tucholke

Principal Consultant

SAP America

Message was edited by: Kevin Tucholke

former_member184114
Active Contributor
0 Kudos

Hi Kevin,

Thanks for your reply.


If you did not have the Runtime Config check OK checked, the existing workflows will continue as normal in the version that they were created in.

Yes, in my current configuration, "Runtime Cnfg Chng Ok" is NOT Checked. The existing workflows are behaving as expected in the earlier version of Workflow.


Now, I will guess that Manager stage is the first stage in your path, any requests that are past that whether you allow them to move to the next version or not would not have any issue (as long as you still have role assignment owners on the role)...you should have no issues.

Yes, in my workflow, MANAGER is the first stage. I would take here a hypothetical number to represent my current request count. I have 10 requests in "Running" status. Out of 10, only 1 request has crossed the MANAGER Stage and remaining 9 are still waiting at MANAGER Stage.

If I understood you correctly, if I generate the next version of MSMP workflow version, ONLY this 1 request which passed the MANAGER Stage will not have any issue. However, other remaining 9 would have issue. Am I correct in this?


The end users in either case, unless you have something strange in the follow on stages in your path, should not even be aware that something has happened.  They might think its strange if you have let the Role Assignment approvers that you have dealt with these differently going forward after a specific date.

May you please help me understand this better?


You should be ok to move forward at a good cutoff (end of day) so that if an approver gets a request that is before a certain date, it may contain these default roles and requests created after that date would not.

I think I should set a cutoff date for this so that a correct version of MSMP be generated to bring this into effect.


For the Default Roles functionality, you should be good to insert the master data in NWBC when you need to.  You will only get the default roles for NEW requests that are created after the data has been created.

Yes, as of now, I have inserted the master data in NWBC and requests are assigned Default Role(s) when a NEW request type is raised.

Please advise.

Regards,

Faisal

Former Member
0 Kudos

Hi Faisal,

1) If you didn't confirm "Runtime Cnfg Chng Ok" then, you would have no issues to get the new version of MSMP in place.

2) And you are right about the MANAGER stage for the default roles. The request which has been processes by the manager will be provisioned with normal way except those which are currently pending at the manager's stage only if that request has any attributes with Default roles. So for these requests, provisioning should happen as per the new MSMP workflows.

3) On Kevin's comment with the end-user: I assume that you have rest of the workflow in new MSMP as it was in the old versions, related to the role-owners stage where approvals are required. So you shouldn't worry about this. I guess this is what Kevin wanted to convey..am I right Kevin?

Regards,

Ameet

former_member184114
Active Contributor
0 Kudos

Ameet,

Thanks for your reply.

1. Is "Runtime Cnfg Chng Ok" used to restrict the current workflow version change? What does it

    signify? Can you share your thought on this please?

2. It means that my CUTOFF plan should be executed to address the issue that might come with requests waiting at Manager Stage. I think I should first get all existing requests processed and then generate the next MSMP WF version. Then allow users to raise requests.

Please suggest.

Just to share with you, I remember earlier I had some of the requests running my test system and then without closing them formally, I generated the next version of MSMP. As a result, these requests got corrupted and could not be process as using the new MSMP WF version. That is why I am taking precautions here in my production system

3. Yes, except this nothing has changed in my current WF.

Regards,

Faisal

kevin_tucholke1
Contributor
0 Kudos

Ameet:

You are totally on base with my comments.

Thanks, Kevin

Former Member
0 Kudos

Hi Faisal,

IF you confirm the check box for "runtime config chng OK" then this will impose the changes in the workflows as per the new/modified generated version on MSMP. If it is not-checked then the workflows will go on continuing as it was.

So, speaking of your scenario, even though you have a new version of MSMP ready to get imported to production, so it will not harm the existing request workflows; which is tested and verified conceptually and practically

You can count on us and go with it.

But if you feel unsecured (of course it is production so taking chances becomes minimal) then yes, you can get the existing/pending requests processed first then you can apply the new versions.

This is what I can suggest at my best, but we always have some experts over us, so even I am looking forward for others to let us know with their thoughts on the same.

And yes, it is always better to have it discussed thoroughly before making it happen.

Regards,

Ameet

Former Member
0 Kudos

Thank you Kevin.

But still I needed you to second my suggestions, if agreed with you.

Regards,

Ameet

kevin_tucholke1
Contributor
0 Kudos

Faisal:

The versioning of the MSMP workflow will take care of any issues from a workflow item perspective.  If you have workflows that get 'corrupted' as you state, this is not as intended and you should raise a CSS Incident on this.  It is up to you to determine if all requests are to stay in the MSMP Workflow version that it started in or if you what any WF changes to be applied to new request as well as requests that are currently in process.  (that is what Runtime Cnfg Chng Ok does).  When this is checked,  at the time the approver opens the request (I.e. Runtime), the system will check the version number of the workflow that it currently is on, and if it is not the current, it will transfer it to the current version.  This is a stage specific setting.

Again, just to be perfectly clear, any request in flight should process correctly in either case (Runtime box checked or unchecked).  The only issue that I can imagine is if you have added a requirement AFTER the fact (i.e. Made a field required, added a custom field, ...) that you now use as a condition in a rule.  If the field is not populated, you will have a problem because it was not required or available when the request was submitted originally, but I would a bigger change than what you are asking about here.

From my Default role comment, I believe that default roles are calculated at the submission of a request.  If the request is in process, and these roles are needed, but not part of the request, analysis would need to be done to ensure that you are getting the expected results for items in flight.

Cheers,

Kevin Tucholke

Principal Consultant

SAP America


former_member184114
Active Contributor
0 Kudos

Dear Kevin,

Thanks for your explanation. It is really getting more interesting!

My below post would seem to you very lengthy. Please bear with me

I think , now I got the significance of "Runtime Cnfg Chng Ok" option: Application will check if any modification is there in the existing workflow (moved through TR). If there is, then it will adapt all the "running" and "new" requests to the new version of  workflow and the intended changes will be applied. In my scenario, at Manager Stage. Please correct me, if needed.

As I have brought to your notice that currently, "Runtime Cnfg Chng Ok" is not checked at my end. Therefore, as you and Ameet told, the existing requests will follow the previous version of WF without any issues and that is what is happening, meaning, requests are getting processed without any issues. This means that, though changes are moved through TR, they are not still in effect.

So far, I generated the version of MSMP Workflow "MANUALLY" in each system. Even in Production system, I did the same. So I was thinking that after moving necessary changes in Production system, I had to generate the new version of MSMP WF. Is my understanding correct?

Secondly, I moved the changes to Production System through TR and I noticed the changes I made and tested in Quality System. What do you think I should do here:

1. Should I always generate the new version of MSMP WF manually in Production System to bring the changes into effect?

2. Should I check the "Runtime Cnfg Chng Ok" Option to reflect if automatically?

I believe TR import will NOT generate a new version of MSMP WF? Because, when I generate it manually, I get the latest version number. Therefore forcing me to believe that MANUAL version generation is necessary.

A TR import will ONLY bring the modifications, but does not generate the latest version of MSMP WF.

Hypothetical Example:

1. Current MSMP Version in Production System = 10

2. Changes are imported in Production System through a TR and I noticed the changes in

    Production System.

3. If I check "Runtime Cnfg Chng Ok" Option , will the MSMP Version in Production System still be 10 and

     changes will be adapted by the application for old and new requests?

May I request you to kindly advise me?

Regards,

Faisal

kevin_tucholke1
Contributor
0 Kudos

Faisal:

You seem to be on the right track.  It is required that you generate the workflow each time MSMP Workflow configuration is transported to an new instance (DEV to QAS to PRD).

You are correct.  The transport does NOT generate a new version when you move it to a new instance.  You can use transaction GRFNMW_GEN_VERSION from the abap screen to do this.  In this way you are not going to the MSMP Configuration screen to have to open that up for change and then generate there.  It will NOT require a transport to do this.

Also, It will NOT matter if the current version matches across your instances.  For example, you may have version 67 in your GRC DEV box, and you may have version 34 in your GRC  QAS instance, and version 23 in your GRC PRD instance.

In regards to activating the Runtime Cnfg Chng OK option, the question you will need to ask is:  Should all requests be updated to the latest version of workflow when changes are made.  If yes, then you want to check this box in all stages.  Personally, in my experience, this is usually activated in my implementations.

Just one more thing you should understand, once you make that change to activate the runtime functionality, only requests that are initiated AFTER that change has been made and the workflow has been generated will be changed.  So for example, you maintain your workflow to activate this field and transport it. After the transport is imported to the next instance, you use the transaction to generate a new version in that instance.  Any existing WF items that exist would not have that box checked as they are on the previous version now.  They would follow the path that they started on and it is not possible to change that.  If necessary to get them to the new version, you would need to cancel the current request and then copy that request to a new one.  I hope that makes sense.

At times when I have made some significant changes that affect the course of the workflow, you may still run into issues.  For example, if you change your EUP settings to begin adding a required field, that change is outside of the course of the workflow generation, and it may cause some issues in existing requests.  There is no 'guide' as to when that will happen, so you would just need to understand what changes you are making and consider what the consequences may be for WF items already existing.

Let me know if you have any other queries.

Cheers,

Kevin Tucholke

Principal Consultant

SAP America

Message was edited by: Kevin Tucholke

former_member184114
Active Contributor
0 Kudos

Dear Kevin,

Thank you so much for helping me understand this.

I will generate the next version of WF and let existing WF items follow the old version as the actions:


1. "Runtime Cnfg Chng OK option" activation  and


2. New WF version generation


does not affect the existing WF items and they will be get processed normal.

Regards,

Faisal

former_member184114
Active Contributor
0 Kudos

Dear Kevin/Ameet,

Let me share the interesting case with you.

I followed as mentioned above: Moved the WF changes and then generated the new version of WF. I have "Runtime cnfg check ok" checked at all the stages.

As per above discussion, I had understanding that old+new requests will be processed without any errors. Unfortunately, I noticed that old requests got failed!

Whereas, new requests are getting processed successfully. I dont know why system is behaving like this

May I know if I missed anything here?

Regards,

Faisal

Answers (0)