Service Definition Builder

Service Definition Builder

In this topic ...

How Do I...
Specifying Inputs
Objects this Builder Creates
Related Topics ...

Overview: Working with Data Services
Service Stub Builder
Service Test Builder

Use this Builder, in conjunction with the Service Operation Builder, to create a Factory Data Service. A Data Service created by this Builder is initially an empty shell that does not contain any operations. Once the Service shell is created by this Builder, use the Service Operation Builder to add specific services to the Data Service.
A data service created by this Builder can be invoked in another model if that model contains a Service Consumer Builder. When you create a data service with this Builder, we can also opt to expose the service as a WSDL/SOAP service.
This Builder also provides support for additional features of the Factory s service-oriented architecture, including:

Stub Model Generation - A stub service data model allows you to build and test front-end presentation models without the need for back end connectivity. This de-coupling of presentation and data access layers facilitates development.
ServiceTest and Troubleshooting - Automatically generated test pages and code provided by this Builder enable you to test a service in-situ, without requiring you to build out a testing front end or elaborate test harness.

How Do I...

Create a Service Provider Model?

There are three basic steps to creating a service provider model:
Create a model that contains a Service Definition Builder that defines and names a service. In this Builder leave the "Make Service Public" input enabled (default) so the service is available to all models in your application. To facilitate testing of the service, enable the "Add Testing Support" input in the Testing Support section.
Next, use an integration Builder (SAP Function Call, SQL Call, Web Service Call, etc.) to create a back end, data access operation.
Use a Service Operation Builder to name this back end data access operation and add it to your service. In this Builder select the operation created by the integration Builder. Add additional operations to your service as required.
Create a Service Consumer model that will use your new data service. In this model place a Service Consumer Builder and select the Service Provider model previously created.
If you selected "Add Testing Support", you can test your service right in the Provider model by simply running the model.

More How do I... Topics

Specifying Inputs

This Builder takes the inputs described in the table below. For help on inputs common to many or all Builders such as those in the Properties input group, see "Using the Builder Call Editor."

Input Name Description
Service Name Provide a name for the service.
Make Service Public Enable to make your service available to any model that contains a Service Consumer Builder.
Disable to make service available only in this model in which this Builder resides.
Generate WSDL This input is available when a service is made public.
Enable to make this service available via WSDL and SOAP.
When enabled, this feature invokes a Web Service Enable Builder to generate WSDL support.
Service State
Maintain State This input controls whether or not a Provider Model maintains state across calls within a session. We can choose:

Stateless - WebApp Variable data is not maintained across calls. A new WebApp instance is created in session for each call.

Stateful - To maintain the state of the service across all calls to the service. WebApp Variable data is stored in user session across calls.

Interface and Stub Models
Interface Model Use this input if you are implementing a provider service that needs to match the interface of another provider model.
If you enter the name of a provider model here, this Builder will check to see if you have implemented the same operations (with the same parameters) as in the interface model. You will see an error for each un-implemented operation.
This functionality is useful when we need to have multiple, compatible implementations of some service functionality, with different back end implementations.
Stub Model If you intend to generate a Stub model, enter the name of that model here.
Such a model will provide a "stub" or dummy data implementation of your service. You can control the use of the stub model with the Service Mapping Registry (XML files in the WEB-INF/config/service_mappings folder). Use the "Generate Stub" button to create a stub model.
If you want to generate a stub data model with real data captured from running a service, enable test support (below). For operations that require inputs, also specify input values in the "Default Inputs" section.
For more information on stub service models, see the help for the Service Stub Builder.
Generate Stub Automatically Enable to force a stub model to be generated every time the model containing this Builder Call is generated.
Use this feature with care since stub model generation can adversly impact overall application performance.
Generate Stub Button This button is available when automatic stub generation is disabled.
Press this button to create a stub model implementation of your service.
The stub service model will contain a public service whose operations have the same signatures as the those in your service, but all of which return constant, stubbed-out data.
Pressing this button will create the model named in Stub Model input above but will not appear in the Navigator pane of Designer until the project is refreshed. Refresh a project by selecting the project name in the Navigator pane and pressing the F-5 button on the keyboard.
Testing Support
Add Testing Support Enable to add automatic testing support for your service.
This will generate test pages for inputs and results of all your service operations, along with an index page for accessing the other pages.
Generate Main Enable to create a "main" method that displays the index page.
Specify Default Inputs Enable to specify default values for testing operations that have inputs.
Default input values are also used when calling the service to generate stub data.
Overridden Inputs This input is available when the Specify Default Inputs above is enabled, and is used to specify default inputs for testing
When you run the model, the input pages will be automatically pre-populated with these values.
Select an operation in the left column, and then specify an input name and value for the selected operation in the right columns.

Objects Created by the this Builder

A variety of WebApp artifacts are created by this Builder. These artifacts include the following LJOs, variables, methods and Data Services:

Data Service

<builderCallName> - Data Service that the Service Operation Builder will add operations to.

Additional Artifacts

When Add Testing Support" is enabled, this Builder generates all the artifacts required for testing, including: Pages (index, and input and result pages for each operation, Methods (required to execute the operations).

Input Name	Description
Service Name	Provide a name for the service.
Make Service Public	Enable to make your service available to any model that contains a Service Consumer Builder. Disable to make service available only in this model in which this Builder resides.
Generate WSDL	This input is available when a service is made public. Enable to make this service available via WSDL and SOAP. When enabled, this feature invokes a Web Service Enable Builder to generate WSDL support.
Service State
Maintain State	This input controls whether or not a Provider Model maintains state across calls within a session. We can choose: Stateless - WebApp Variable data is not maintained across calls. A new WebApp instance is created in session for each call. Stateful - To maintain the state of the service across all calls to the service. WebApp Variable data is stored in user session across calls.
Interface and Stub Models
Interface Model	Use this input if you are implementing a provider service that needs to match the interface of another provider model. If you enter the name of a provider model here, this Builder will check to see if you have implemented the same operations (with the same parameters) as in the interface model. You will see an error for each un-implemented operation. This functionality is useful when we need to have multiple, compatible implementations of some service functionality, with different back end implementations.
Stub Model	If you intend to generate a Stub model, enter the name of that model here. Such a model will provide a "stub" or dummy data implementation of your service. You can control the use of the stub model with the Service Mapping Registry (XML files in the WEB-INF/config/service_mappings folder). Use the "Generate Stub" button to create a stub model. If you want to generate a stub data model with real data captured from running a service, enable test support (below). For operations that require inputs, also specify input values in the "Default Inputs" section. For more information on stub service models, see the help for the Service Stub Builder.
Generate Stub Automatically	Enable to force a stub model to be generated every time the model containing this Builder Call is generated. Use this feature with care since stub model generation can adversly impact overall application performance.
Generate Stub Button	This button is available when automatic stub generation is disabled. Press this button to create a stub model implementation of your service. The stub service model will contain a public service whose operations have the same signatures as the those in your service, but all of which return constant, stubbed-out data. Pressing this button will create the model named in Stub Model input above but will not appear in the Navigator pane of Designer until the project is refreshed. Refresh a project by selecting the project name in the Navigator pane and pressing the F-5 button on the keyboard.
Testing Support
Add Testing Support	Enable to add automatic testing support for your service. This will generate test pages for inputs and results of all your service operations, along with an index page for accessing the other pages.
Generate Main	Enable to create a "main" method that displays the index page.
Specify Default Inputs	Enable to specify default values for testing operations that have inputs. Default input values are also used when calling the service to generate stub data.
Overridden Inputs	This input is available when the Specify Default Inputs above is enabled, and is used to specify default inputs for testing When you run the model, the input pages will be automatically pre-populated with these values. Select an operation in the left column, and then specify an input name and value for the selected operation in the right columns.