Transitions

Purpose

A transition is a relationship between two states indicating that 1) a certain action will be performed on an object in the first state ( from state ), and 2) the object will enter the second state ( to state ) when a specified event occurs and specified conditions ( guard conditions ) are satisfied.

On such a change of state, a transition is said to fire . Until the transition fires, the object is said to be in the from state; after it fires, it is said to be in the to state .

Transitions are elements that represent an object’s behavior within a behavior profile. Only one transition can be fired in response to an event.

Process Flow

Defining Transitions

You must define the transitions that your object can undergo. You begin by listing the required transitions and then define them within your behavior profile.

You do this in Customizing by choosing Start of the navigation path Customer Relationship Management Next navigation step Master Data Products Objects Object Integration Framework (OITF) Configure OITF State Manager Define Behavior Profile End of the navigation path .

The Event Name , From State , and To State are mandatory entries and form the key. For transitions that do not cause a state change, the to state is the same as the from state; otherwise they are different.

If an action needs to be executed when a transition is fired, then you specify an action against the transition; otherwise an action is not required.

Example Example

The list of transitions required for the High Tech Software Entitlement is defined within behavior profile ISHT_BP_ENTIT_PER as shown below.

End of the example.

Transitions for Behavior ProfileISHT_BP_ENTIT_PER

Event Name	From State	Guard Condition	To State	Action
ISHT_DOWNLOAD	ISHT_ACTIVE	ISHT_GC_IDWNL_MEXPR	ISHT_ACTIVE	ISHT_AC_UPD_BIN_VER
ISHT_DOWNLOAD	ISHT_ISSUED	ISHT_GC_IDWNL_MEXPR	ISHT_ISSUED	ISHT_AC_UPD_BIN_VER
ISHT_EXTEND_MAINTENANCE	ISHT_ACTIVE		ISHT_ACTIVE	ISHT_AC_SET_MAINT
ISHT_EXTEND_MAINTENANCE	ISHT_MAINTENANCE_EXP		ISHT_ACTIVE	ISHT_AC_SET_MAINT
ISHT_MAINTENANCE_EXPIRED	ISHT_ACTIVE		ISHT_MAINTENANCE_EXP	ISHT_AC_EXP_MAINT
ISHT_MAINTENANCE_EXPIRED	ISHT_ISSUED		ISHT_ISSUED
ISHT_PRODUCT_REGISTERED	ISHT_ISSUED		ISHT_ACTIVE	ISHT_AC_SET_REG
ISHT_PRODUCT_RETURNED	ISHT_ACTIVE		ISHT_INACTIVE	ISHT_AC_RVK_ENTIT
ISHT_PRODUCT_RETURNED	ISHT_ISSUED		ISHT_INACTIVE	ISHT_AC_RVK_ENTIT
ISHT_PRODUCT_RETURNED	ISHT_MAINTENANCE_EXP		ISHT_INACTIVE	ISHT_AC_RVK_ENTIT
ISHT_UPGRADE	ISHT_ACTIVE		ISHT_INACTIVE	ISHT_AC_UPG_PROD
ISHT_UPGRADE	ISHT_MAINTENANCE_EXP		ISHT_INACTIVE	ISHT_AC_UPG_PROD

A diagram showing the defined transitions could appear as follows:

This graphic is explained in the accompanying text.

Guard Conditions

OITF uses guard conditions to protect a transition. Guard conditions enable you to program a logical condition that is checked before firing a transition. If the guard condition is evaluated to be true, a transition is fired; otherwise it is not.

Guard conditions give you the flexibility to model multiple transitions for an event and a from state , where each transition is protected by a guard condition such that none or only one guard condition is evaluated to be true when the event is raised. In other words, if there is a need for an object to transition from a from state to more than one to states when an event is raised, you can model all such transitions and protect each one of them with a guard condition. This means that out of the many possible transitions none, or only one transition, is fired (guard condition of exactly one transition is evaluated to be true).

Note Note

A transition that is not protected by a guard condition is treated as a transition with a guard condition that is always evaluated to be true.

End of the note.

Defining a Guard Condition

A guard condition is an ABAP class that implements the guard condition interface IF_COM_IOITF_GC specified by OITF.

Name your guard condition, for example, MY_GUARD_CONDITION .
Using transaction SE24 create a Usual ABAP Class with the name CL_MY_GUARD_CONDITION .
On the Interfaces tab, specify IF_COM_IOITF_GC .
On the Methods tab, select the method IF_COM_IOITF_GC~EVALUATE .
Enter the necessary code. The template below is provided as an example. Then save and activate your entry.

METHOD if_com_ioitf_gc~evaluate.

DATA: lv_rc TYPE comt_ioitf_ty_rc VALUE IS INITIAL.

* Before you can access the Application Context you must convert it

* Into the format that you specified for the corresponding Event.

DATA: lo_my_appl_ctx TYPE REF TO cl_my_appl_ctx VALUE IS INITIAL.

lo_my_appl_ctx ?= io_appl_context.

* --> Begin: Put your code

* You can access the information in Application Context as follows -

* lv_iobj_guid = lo_my_appl_ctx->iobj_guid.

* ...and so on!

* --> End: Put your code

* Return code (0 = True; 1 = False)

rc = lv_rc.

ENDMETHOD.

Registering a Guard Condition

You have to register your guard condition before you can use it with OITF. You register a guard condition with OITF in Customizing by choosing Start of the navigation path Customer Relationship Management Next navigation step Master Data Products Objects Object Integration Framework (OITF) Configure OITF State Manager Guard Condition Register Guard Condition End of the navigation path .

Example Example

The following list of guard conditions is registered for the High Tech Software Entitlement Demo application.

End of the example.

OITF Guard Conditions for HT Software Entitlement Demo

Guard Condition	Description	Guard Condition Class
ISHT_GC_IDWNL_MEXPR	ISHT:Initial download & maintenance expiration	CL_ISHT_GC01

Note Note

See the table above Transitions for Behavior Profile ISHT_BP_ENTIT_PER which shows that the transitions modeled for event ISHT_DOWNLOAD, from state ISHT_ACTIVE and ISHT_ISSUED respectively, are protected by a guard condition.

End of the note.