Transitions 

Purpose

A transition is a relationship between two states indicating that 1) a certain action will be performed on an individual object in the first state (from state), and 2) the individual 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 individual 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 individual 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 individual object can undergo. Begin by listing the required transitions and then define them within your behavior profile as follows:

...

      1.      From the SAP Implementation Guide (IMG) choose Customer Relationship Management à Master Data  ® Products à Individual Objects à Individual Object Integration Framework (IOITF)à Configure Individual Object Integration Framework’s State Manager à Define Behavior Profile

      2.      Select your behavior profile then choose the Transitions node in the tree displayed on the left.

      3.      Enter the event name, from state, guard condition, to state, and action.

Event name, from state and to state are mandatory and form the key.

If an action needs to be executed when a transition is fired, then an action is specified against the transition; otherwise, no action is specified.

For transitions that do not cause a state change, to state is same as from state; otherwise they are different.

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

Transitions for Behavior Profile ISHT_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

 

After having defined the transitions the basic state diagram could look like this:

Guard Conditions

IOITF uses guard conditions to protect a transition. Guard conditions provide you the opportunity 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 individual 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).

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.

Using Guard Conditions to Protect a Transition

Follow the steps below to define, register, and use guard conditions.

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

To define a guard condition:

...

      1.      Name your guard condition, for example, MY_GUARD_CONDITION.

      2.      Go to transaction SE24 and create a Usual ABAP Class with the name CL_MY_GUARD_CONDITION.

      3.      On the Interfaces tab, specify IF_COM_IOITF_GC.

      4.      On the Methods tab, choose the method IF_COM_IOITF_GC~EVALUATE.

      5.      Enter the necessary code here, then save and activate your entry.

The following template could be used:

 

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 must register your guard condition before using it with IOITF. You can register a guard condition with IOITF as follows :

...

      1.      From the IMG, choose Customer Relationship Management à Master Data  ® Products à Individual Objects à Individual Object Integration Framework (IOITF) à Configure Individual Object Integration Framework’s State Manager à Guard Condition à Register Guard Condition

      2.      Enter the guard condition name, description, and class.

For example, below is the list of guard conditions registered for the High Tech Software Entitlement Demo application.

IOITF 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

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.