When a driver entry is expanded, the list of services associated with this driver is also displayed.
Left-clicking the web service name brings up the Service Properties in the Properties view.
Right-clicking the web service name brings up the Service Context Menu
This section also provides information about Lifecycle Governance (LG)
When a web service is selected, the following information is displayed.
Name : The name of the web service. This will determine the WSDL URL and service endpoint.
Driver: The driver in use for this web service.
SBCS/MBCS : The SingleByte/MultiByte codepages used for data conversion with this service.
Service Status: For more details see here
Service Identification. These fields vary on the type of service. They define the resource-specific parameters for this service.
Service Meta Information: These fields vary on the type of service. They define the resource-specific meta parameters for this service, often used when creating new resources. For example the "MaxIsn" value (setting the maximum amount of records which can be stored on the file) to be used when creating a new Adabas file.
Usage Governance Information. For more details see here
Important:
The button must be clicked to
publish the changes to the server. The button is located in the top-right
corner of the properties view.
Edit DataView: Edit the DataView associated with the selected Service. The dataview will open in the Editor View, and the details of each field will appear in the Properties View. Changes will not be reflected on the web service (WSDL) until the file is saved.
Rename Service: Rename the service. This will have consequences on the URL of the WSDL, and the endpoint of the web service.
Duplicate Service: Create a new web service that is a copy of the existing. This service needs to have a different name from the original.
Refresh Service: clears the internal cache on the Portus server to pick up changes to the (Business)DataView, XSD or XSL
Show WSDL : Display the WSDL for this service. This is the starting point of for any web service clients that wish to consume this web service.
Remove Service: Remove this service from the Portus Server
Important:
If the Remove orphaned dataviews box is checked, the
internal configuration files (XRD, XSD and XSL) will also be deleted from the
server.
Create Physical Resource: Create a back-end resource (E.g Adabas file/MySQL Table/etc), physically, based on the Portus service.
Delete Physical Resource: Physically delete a back-end resource described by the web service.
Select "Rename Service" from the context menu
This will bring up a dialog and allow you to choose a new name for the service. By default the original service name will be appended with the string "_Rename".
Enter the new name of your choice and click OK.
The service will appear in the list of services with its new name immediately
This function will create an initially exact copy of a service. You will be prompted to enter a name for the copy.
The copy will appear in the list of services immediately
Modify the Dataview and/or service parameters as needed.
Copying service definitions from one server to another is possible in two ways
using the Copy Wizard
using drag-and-drop
Right-click the service you wish to copy, select the Copy Service definitions ... function from the context menu.
Assumptions:
Both Portus Servers are accessible from the Control Centre.
If migrating services from a previous version of Portus, the utility is invoked from the most recent Control Centre.
Both Portus servers have the same drivers enabled and configured. See here for more info.
Note:
"Same drivers" refers to the type of drivers, they need
not necessarily be of the same name.
Process:
In the Portus you wish to copy from, choose the service you wish to copy by right-clicking and choosing Copy Service Definitions
Choose the server you wish to copy the service to.
If no driver with the same name exists on the target server you will be given the option to choose another driver of the same type as the source.
If you wish to overwrite the service on the target server, check the Overwrite exsting.... box.
The status of the copy will be written to the Action Log, and this you can double-click this to get more information.
Portus Services, which are essentially "Services", can be registered with an UDDI Business Registry, for example Software AG's Centrasite, so that any UDDI enabled client application can find an exposed service, retrieve its signature, issue requests agains it etc.
These are the steps required to register a Service with an UBR:
Define a UDDI Business Registry to the Portus Control Centre (from the Portus Eclipse Preferences dialog)
Select the function from the context menu
Select one of the predefined UDDI Business Registries, enter the user credentials required to be able to publish
Select a Business registered with the UDDI Registry for the selected account, click to continue
After successful completion of the registration process the service and tModel registry keys will be shown
Click
The term Lifecycle Governance (LG) is used to define the Portus handling of distinct versions and states of web services. States allow the administrator to define services in Test mode, move them to frozen production environments, and, in time, deprecate them from use. Versioning allows the administrator to define multiple versions of a service.
The WSDL is the main starting point for web service clients who wish to consume Portus web services. As part of the Portus LG support, it is possible to create multiple versions of the WSDL (and so the web service), thus allowing different clients to consume the different versions. It also allows modifications to be made to existing services, safe in the knowledge that existing clients will not be affected.
When requesting the WSDL, Portus will always return the most recent version. To retrieve a specific version, the __version argument must be provided on the WSDL URL. E.g.
http://host:port/myService?WSDL&__version=5The WSDL will contain a service endpoint which reflects the service version.
When working with REST requests, the same __version argument can be used.
http://host:port/myService?LIST&__version=5&ID=4*Internally, a new DataView is created for every service version. The DataView name will have the version number appended on the end of the file name.
There are 4 statuses a Portus service can be in:
Test: The service may be modified as often as is required to bring the service to a point where it is to be made available to others
Frozen: The DataView (metadata) for this service cannot be modified. If the service is being migrated from a Test status, it will be assigned a version number incremented by 1.
If a newer version of this service exists, clients will receive an informational message in the SOAP Header response.
When the Administrator edits the dataView of a frozen service, a new version of this service will be created, it's status set to test, and it's version number incremented by 1.
Deprecated: Clients will still be able to call a service with this status, but they will receive a warning message in the SOAP headers. A warning message will also be written to the Portus log, and the client should be urged to upgrade.
Historical: The service is no longer active, and clients who attempt to call this service will receive a SOAP fault.
When a service is in a specific status, the following transitions are possible
| Current Status | Next Status |
| Test | Frozen |
| Frozen | Test, Deprecated |
| Deprecated | Test, Historical |
| Historical | Deprecated |