You can provide your own services in the meshMarketplace via the Marketplace Development. The functionality is currently only available for Customer Admins. You can provide your service (e.g. databases, message brokers, filesystems, etc) by implementing the Open Service Broker API. Your implementation of an application that manages these services is called a Service Broker. Services provided by you can be consumed by other users of the meshPortal. A short overview and some specifics that should be considered when writing a Service Broker for the meshMarketplace are described here.
You can find the Marketplace Development in your meshCustomer Account Area. Via the Service Broker section in the navigation on the left, you get to the maintenance area for your service brokers. You can register and publish your Service Broker. Analytics screens that provide you with Usage and Logging Data are also available.
Register your Service Broker
Registering your Service Broker does not publish your Service Broker directly for all users. Initially only your meshCustomer will have access to this Service Broker. We call this type of Service Broker a private Service Broker. It allows you to test and develop your Service Broker via the meshMarketplace development from the first steps on. A new Marketplace Platform for your Customer will be available for your projects after registering a Service Broker. When you select it for a project, your own Marketplace will be available on the project.
You can register your service broker via the Register Service Broker button. The following information must be provided for this:
- Name: Give a name to the service broker you want to register. It is mainly used as a display name for your administrative Screens.
- Identifier: Globally unique, immutable identifier for your Service Broker, used in API requests and logs. Choose wisely as this identifier cannot be changed later on.
- Endpoint: Root URL to your Service Broker's API endpoint. It must start with "http(s)://". Below this API endpoint the /v2/catalog endpoint must be available, as described in the Open Service Broker API.
- Basic Auth Username: Communication between the meshMarketplace and your Service Broker is secured via HTTP Basic Auth. Therefore username and password have to be defined here, so the meshMarketplace can authenticate successfully to your Service Broker. Enter the username for HTTP Basic Auth here. The username can be changed at any time.
- Basic Auth Password: Enter the password for your HTTP Basic Auth. A set password will never be shown to you again. This password will be stored encrypted in the database. You can set a new password at any time. No restrictions regarding the characters used in your password are applied. Please be sure to always use a secure password!
- Development Mode: As all communication should be secured via SSL by using an https endpoint, it might be too complicated to provide a valid certificate during development. Therefore SSL validation of your Service Broker's certificate can be disabled via this Development Mode. This is only possible for the Development Service Broker only your meshCustomer has access to. Published Service Brokers always need a valid certificate!
Edit Service Broker Registrations
Data entered when registering your service broker can also be edited afterwards. Only the identifier cannot be changed anymore.
Refresh Service Broker Catalog
Service Brokers provide the catalog of all available service according to the Open Service Broker API. The meshMarketplace periodically calls the catalog endpoint and updates the available services internally. To force this refresh of your Service Broker's catalog, you can click the Refresh Catalog button in the list of your Service Brokers.
Publish your Service Broker
As soon as your Service Broker is production-ready, you can publish it to the public meshMarketplaces, so all users of the meshPortal can use it. You should provide a new deployment of your Service Broker in order to publish it. Your private service broker configuration will remain untouched when publishing the service broker. The private Service Broker will still be available for your meshCustomer.
To publish your Service Broker, click the Publish Service Broker button for the according Service Broker.
You can choose which public Marketplace you want to publish your Service Broker to. For many services, like databases, storage, etc, it makes sense to provide the Service Broker in the same Location the applications consuming the service are running. This enables best latency, security and performance for using your services. But there are also other Service Brokers like a service that provides user credentials for using an internet proxy, which are independent of the Location. In these cases the Service Broker can simply be published to the Global Location.
Location-based Service Brokers should be running independently from each other in all Locations they are published to. Therefore different endpoints and credentials have to be configured for every Location. Endpoints of published Service Brokers must always use an https endpoint, because that's the way how security can be established for the communication between the meshMarketplace and your Service Broker.
When you publish your Service Broker it won't be available in the meshMarketplace you published it to directly. A meshAdmin has to approve your Service Broker first.
Refresh Catalog of Published Service Broker
Like for your private Service Broker, you can also actively refresh the catalog of your published Service Broker. This is done via the Refresh Catalog button in the Publishing list of your Service Broker.
The Analytics functionality for Service Owners is available to Customer Admins, who already registered a Service Broker.
Debugging your Service Broker
Reviewing failed Service Instances
From the meshCustomer Account area, you can access an overview of all failed service instances of your service brokers under the "Failed Instances" menu entry. This allows a quick error analysis of failed service broker calls. The list shows you an overview about all failed Service Instances with the specific local id, name, service plan and the last operation.
Service Communication Logs
Especially when an error occurs during a service broker call, detailed information about the request that was made from the meshMarketplace to the service broker helps in analyzing the reason why a call failed. But the communication logs are not only available in error cases, they are availbale for all requests that were made from the meshMarketplace to the Service Broker. Instead of implementing a detailed request and response logging in every service broker, the meshMarketplace provides this information for all service brokers.
All relevant information like the request date and the type of operation that was executed, all request and response headers as well as the body of the request and in case of an error also the response from the service broker, are available. The duration of the call and information about the used Service Plan and Service Instance are also available. This information, combined with the application logs of the service broker should provide all information for a successful error analysis.
The communication logs are available for private and published service brokers via the Communication Logs button in the according service broker list. In case of private service brokers the communication logs can provide you with helpful insights during the development phase or the marketplace integration phase of your service broker.
A searchable overview of all communication logs is the starting point for analyzing communication logs. When more details about a specific log is needed, the info icon in the list of logs provides you with all details that are available to a specific call that was made.
Searching the Communication Logs
Searching the communication logs to e.g. find a specific issue that was reported or to have a look at a specific call that was made is an essential feature of the communication logs. The search is executed automatically while entering your search criteria. You can search by the following criteria:
- Request Date: When e.g. a user reported that an issue occurred at 10 o'clock at a specific day, you can quickly find the related communication log by searching for the request date. The date you search for will be interpreted as the latest request date to find. So you will retrieve all communication logs before this date. As the ordering of the list is descending, the communication log that is closest to the requested date will appear at the top of the list. The date must be entered in format yyyy-MM-dd HH:mm:ss (e.g. 2019-01-01 10:00:00). Enter the date in your local timezone here.
- Operation Type: You can filter by the different operation types, that are defined by the OSB specification. A dropdown with the different operation types like FETCH_CATALOG or PROVISION_INSTANCE is available for selection.
- Response Code: The response code (HTTP Status Code) is an often used filter criteria as you can search e.g. for all error responses by entering ">399", which will return all requests that failed with a client (4xx) or server (5xx) HTTP response code. But you can also search for a specific response codes like "403".
- Service Plan: When you know that there was an issue with a specific service plan, you can search for all service plan related requests by entering the id of the service plan, that you defined in your service broker catalog.
- Servcie Instance: When you know that an error occurred for a specific Service Instance, you can search for all related logs by entering the id of the service instance.
Deletion of Service Brokers
The deletion of a Service Broker is only allowed if it has not been published and approved. As soon as an approved Service Broker exists users can create Service Instances from your services. The deletion of a Service Broker could affect productive data of other users and is therefore not possible.
Unpublished, unapproved Service Brokers can be deleted from the list of Service Brokers via the trash button. A safety dialogue pops up, where you have to enter the name of the Service Broker for confirmation. The deletion will only delete the Service Broker in the meshPortal. No deprovisioning will be triggered in the Service Broker! You have to clean up existing Service Instances in your Service Broker by yourself!
After you have published your Service Broker you can also revoke this publishing by clicking the trash icon in the Publishing list of your Service Broker as long as it has not been approved.
Deactivation of Service Brokers
If a Service Broker has been published and approved it can no longer be deleted because there may already be provisioned service instances. Instead, a published Service Broker can be deactivated. Deactivating a Service Broker does not delete any service instances or bindings but ensures that no new service instances can be created. Marketplaces will no longer show any services offered by this broker and if the Service Broker uses a dashboard client it will no longer be available.
Deactivating a Service Broker is permanent and irreversible!