9.1 Lifecycle Transitions

[sdrzewiczewski]

I'm in the process of moving away from using Promotion Notices toChange Notices for our nonproduction changes.

In our Promotion Process we use the Lock transition to move an object to Under Review. If thePromotion is cancelled or rejected, the objects go back to theoriginating state of the object. Also if we Rework the Promotion, it goes back to the originating State which will allow the users to edit the objects before going through the review cycle again.

I'm trying to figure outhow to do the same thing within the ECN process.

I have a method that I created to set the changeables state to a given state. So it can be Under Review or say Prototype.

But if they need to Rework the change, I want the objects to go back to their original states. To me that seems like I need to create some variable and store a list of the objects and their starting state... I'm not sure I can use the new Refine transition, since it has not been set in my current lifecycle template.

Just wondering what approach I should take to solving this.

Thanks,

Steve D.

[ssenthil]

Hi Steve

One of the approaches is retrieving the lifecycle history of the resulting
data and get the state one prior to the current state. There by you can
steer clear of any local variables for keeping track of the states.



HTH



Thank you and have a great time.

Best Regards

Swamy Senthil

Principal Solutions Architect

973 216 0456(M); 973 324 2729(W); 866 908 6561(F)

Work Email: swamy.senthil@swasen.com

LinkedIn Profile:

[MichaelIbosh]

Swamy/Steve,
I also am faced with this same type of problem. I thought of adding an IBA that contained the previous state, but am having problems with checkout/checkin when it comes to family table parts. Do either of you have any information on how to get the lifecycle history of the resulting data objects?
Mike

[RussPratt]

Place a "Set State" Robot in your workflow loopback path.

Russ

[ssenthil]

Hi Mike



//wto is the object of interest.

QueryResult lifecycleResult =
LifeCycleHelper.service.getHistory((wt.lifecycle.LifeCycleManaged)wto);

if (lifecycleResult.hasMoreElements()) {

LifeCycleHistory lifecyclehistory = (LifeCycleHistory)
lifecycleResult.nextElement();

String lifecycleState = lifecyclehistory.getState().toString();

//lifecycleState is the State key. Have a logic here for finding the State
that prior to the current.

}







Thank you and have a great time.

Best Regards

Swamy Senthil

Principal Solutions Architect

973 216 0456(M); 973 324 2729(W); 866 908 6561(F)

Work Email: swamy.senthil@swasen.com

LinkedIn Profile:

[MichaelIbosh]

Thanks a bunch, I'll try this out and let you know how it goes OK. In my case, the workflow is setting all of the objects to a UNDERREVIEW state for checking, if a rework loop is started, the state of the objects needs to go back to the previous state before the rework can be completed.

[sdrzewiczewski]

Thanks Swamy! I'll give it a try later. I was thinking that it may be
something that simple, but couldn't quite connect the dots.

[MichaelIbosh]

Swamy,
Thanks, this approach works great!! I'm using it for change activities/notices that have resulting objects that are in different InWork states (concept, prototype, industrialization, production).
Mike