Implementing the Design Time for a New Callable Object Type 

Use

For each callable object type, you create and maintain all object using the same user interface. It is a wizard that leads the user through a number of screens where the different aspects of the callable object definition are set.

In the design time of your new callable object type, you make sure that all relevant screens of the wizard are displayed, and that data is handled consistently.

Procedure

1. Set Up Your Project

...

       1.      Create a new Web Dynpro development component, and add dependencies to the following DCs:

¡        caf/eu/gp/api (public part external)

¡        caf/eu/gp/api/wd (public part COType)

¡        com.sap.security.api.sda

For more information about Web Dynpro DCs, see The Web Dynpro Project in the NWDI.

       2.      Create a new Web Dynpro component.

       3.      Add the interface com.sap.caf.eu.gp.co.dt.IGPCOConfiguration to the list of implemented interfaces.

2. Initialize the Component and Obtain References to the Logical and Physical Callable Object

You can initialize the Web Dynpro component in different modes for creating a new callable object, editing or displaying an existing one. The framework calls the appropriate method when the user creates an object, displays or edits one. Your task is to ensure that you implement the behavior that you expect for you component in each of these modes.

...

       1.      Use the wdDoInit()component controller method to get the references to the logged-in user and to create the user context. Optionally, you can then set the value to a context parameter, so that you can transfer it easily.

Creating the User Context in the Component Controller

public void wdDoInit()   {     //@@begin wdDoInit()   try{     IUser sapUser = WDClientUser.getCurrentUser().getSAPUser();     IGPUserContext userCtx = GPContextFactory.getContextManager().createUserContext(sapUser);   } catch (Exception ex){ ... } //@@end

       2.         To initialize the component properly, use the following methods:

¡        initializeCreate()

Used when the framework creates the component and intends to use it for the creation wizard.

¡        initializeDisplay()

Used when the framework changes the component and intends to use it for a maintenance dialog. You must make sure that the method enables read-only mode on the callable object definition. For example, you can use the method to set a Boolean parameter in the Web Dynpro context that imposes read-only access to the data.

¡        initializeChange()

Used when the framework changes the component and intends to use it for a display dialog.

       3.         Use the initialization methods to get a reference to the logical and physical callable object.

Callable Objects and Physical Callable Objects are specializations of the more generic development objects.

A logical callable object is an instance of the com.sap.caf.eu.gp.co.api.IGPCallableObject interface. It holds the metadata for the callable object definition. The physical representation of an object is an instance of com.sap.caf.eu.gp.co.api.IGPPhysicalCallableObject. The relation between logical and physical objects is one-to-many. The relevant physical object is determined at runtime based on the execution context.

Depending on your own programming style, you can do this either in the interface or in the component controller. You can also use context parameters for these references.

Initialization in the Component Interface Controller

public void initializeCreate( com.sap.caf.eu.gp.co.api.IGPCallableObject logicalObject, com.sap.caf.eu.gp.co.api.IGPPhysicalCallableObject physicalObject )   {     //@@begin initializeCreate()     m_logicalCO = logicalObject;     m_physicalCO = physicalObject;     //@@end   } ...   //@@begin others   private IGPCallableObject m_logicalCO;   private IGPPhysicalCallableObject m_physicalCO;   //@@end }

3. Display the Required Wizard Screens

...

       1.      To display the type-specific screens, implement the following methods:

¡        showSelection()

Displays the select view, which is used for choosing the actual implementation or the target object of the callable object.

This view is always displayed in the callable object creation wizard.

¡        showImportParams()

Displays the import parameters view, which is used for either displaying or modifying the input parameters of the callable object.

¡        showExportParams()

Displays the export parameters view, which is used for either displaying or modifying the output parameters of the callable object.

¡        showConfigParams()

Displays the configuration parameters view, which is used for configuring the behavior of the callable object by maintaining technical parameters.

Methods in the Component Interface Controller for Displaying Wizard Screens

public void showSelection( )   {     //@@begin showSelection()     m_screen = SCREEN_SELECTION;     wdThis.wdFireEventChangeScreen(m_screen);     //@@end   }

When you register your callable object type, you can choose which views are to be displayed in the wizard by setting its visibility to true. If you create a structure for the input and output parameters, or add configuration properties to the physical callable object, the relevant view is displayed.

       2.      To check if a screen can be left, use the canLeaveScreen() method.

In this method, you can fire an event, which is then handled in each individual screen.

This method is called:

¡        When the framework wants to check the data for consistency

¡        Before component destruction

This method can be called several times during the lifetime of one instance.

       3.      To determine if there are unsaved changes, use the hasUnsavedChanges() method.

You can also fire the event OnSubScreenNavigation. When the visible parameter is set to true, you get a screen area with your own buttons and the framework hides its own ones.

4. Implement the User Interfaces

...

       1.      Implement views for each wizard screen – select, input, output, and configuration.

You can use a dispatcher view to process the event fired when a screen is changed and to send the wizard to the proper screen. You link the dispatcher view to the other views, and pass the required data across the views by means of plugs.

You can then use the plug handlers in the views to set context parameters and initialize the objects you need for the relevant view.

Event Handler changeScreen in the Dispatch View Controller

public void changeScreen(com.sap.tc.webdynpro.progmodel.api.IWDCustomEvent wdEvent, int screen )   {     //@@begin changeScreen(ServerEvent)       switch (screen)       {          case NewCOType.SCREEN_SELECTION :             wdThis.wdFirePlugToSelect();             break;          case NewCOType.SCREEN_IMPORT_PARAMS :             wdThis.wdFirePlugToInput();             break;          case NewCOType.SCREEN_EXPORT_PARAMS :             wdThis.wdFirePlugToOutput();             break;          case NewCOType.SCREEN_CONFIG_PARAMS :             wdThis.wdFirePlugToConfig();             break;       }     //@@end   }

       2.      In the select view screen set the configuration properties that define the relevant callable object type.

For example, if the callable object definition requires an endpoint alias, you can define a configuration parameter for the alias, and set the value that the user has entered to the physical callable object instance.

You can also set any read-only properties that you define for your object – result states, and even input and output structures if they are not to be changed in the other wizard screens. You can do it in the canLeaveScreen() event handler, for example.

Event Handler canLeaveScreen in the Select View Controller

//read a parameter from the context IWDAttributeInfo urlAttributeInfo = wdContext.getNodeInfo().getAttribute(CONTEXT_ID_URL); ... //set the value to the physical callable object IGPPhysicalCallableObject physobj = wdContext.currentContextElement().getPhysicalCallableObject(); physobj.setConfigProperty( "URL", url ); //define a result stat physobj.addResultState("COMPLETED", "Completed");

       3.      Create the structures for the input and output parameters of the callable object, if they are relevant for your type. To define a structure for the input and output parameters, you use the interface com.sap.caf.eu.gp.structure.api.IGPStructureInfo.

The framework automatically sets the root structures to the physical callable object. The example below shows which methods you can use in case you want to add a substructure or a parameter to the root structure. Typically however, you do not need to do it in the callable object type implementation. The callable object itself implements the logic for adding substructures and attributes.

Plug Handler in the View Controller

try {       IPrivateVInput.IContextElement ctxtElement = wdContext.currentContextElement();       // retrieve a reference to the callable object from the context       IGPCallableObject logobj = ctxtElement.getCallableObject();       //read the root input structure and add an attribute       IGPStructureInfo inputStructure = logobj.getInputParameters();       IGPAttributeInfo inattr = inputStructure.addAttribute("parameter", IGPAttributeInfo.BASE_STRING);       inattr.setMultiplicity(IGPAttributeInfo.MULITIPLICITY_0_1);       // read the root output structure and add an attribute       IGPStructureInfo outputStructure = logobj.getOutputParameters();       IGPAttributeInfo outattr = outputStructure.addAttribute("parameter", IGPAttributeInfo.BASE_STRING);       //set the structures to the physical object       IGPPhysicalCallableObject physobj = ctxtElement.getPhysicalCallableObject();       physobj.setInputParameters(inputStructure);       physobj.setOutputParameters(outputStructure); }

Result

Next you must implement the runtime part of the callable object type.

See: Implementing the Runtime for a New Callable Object Type