What's new?

IBM Industry Solutions Workbench offers with Event Support 2.0 the possibility to connect to a central Schema Registry and manage schemas via the Solution Designer. A schema will be used to describe the payload structure of an event, which is published on your message broker. When modelling events in a Low-code Service project, one of the shared schemas in the registry can be chosen and assigned to the event easily. This way you can ensure, that the payload is handled correctly while producing and consuming events even across multiple services.

A central schema registry is helpful to ensure governance while dealing with the event payloads. It acts as shared repository, which holds the definitions of the possible payload structures. Those are used and therefore help to define a reliable contract between event producers and consumers. Additionally, the schema registry gives the possibility to create new versions of a schema, so that it can evolve over time while ensuring compatiblity with older versions. For the time being for existing projects, a compability mode for the Event Support 1.0 is available. Nevertheless, we recommend to use schemas defined in the schema registry as payload for the events and migrate them to Event Support 2.0.

IBM Industry Solutions Workbench is using pre-defined helm chart templates for the build and deployment of Service Projects. This helm charts can be adjusted or completely overridden for specific Service Projects depending on your needs and requirements.

Read more about custom helm charts.

For the creation of an API Namespace in Low-code Project now any valid Open API specification file can now be uploaded. So far you have been limited to the supported model of IBM Industry Solution Workbench. Also, so far unsupported elements of an API Specification are now available and code for the implementation will be generated upon availability. To maintain those elements besides the modelling an Expert View to directly edit the specifiation is available.

Read more about API Namespaces

We completely renewed the way to integrate with external REST APIs in order to make it easier to work with and to reduce the amount of mapping effort while implementation.

Each integration namespace is associated to exactly one API dependency, which is representing a REST API to a service or external endpoint. The operations of the API specification are shown and graphically visualized. Access to the operations and the service stub is provided from all namespaces of the project. This way, necessary mappings between different namespace types is now obsolete. And in accordance with that, the enforcement of modeling and using Integration Services has been skipped. Nevertheless, Integration Services still can and should be used where appropriate.

In additon to that introduces IBM Industry Solutions Workbench now the possibility, to simply select an API specification of an other service project and create an API dependency out of that.

Read more about the renewed Integration Namespaces

The Local Marketplace service (which covered the functionality to export, store and import project templates) is now succeeded by the feature Asset Catalogs. An asset catalog is backed by a git repository and holds entries to assets (project templates) which have been shared. It allows easier management and comes along with the possibility to configure more than one Asset Catalog. Thus enabling, sharing of assets across environments with one click. Also, publicly available asset catalogs can be provided and used.

Read more about Asset Catalogs.

A Component Repository is a combination of Helm Chart Repository and Container Image Registry that is configured within the tool. Every component, that is built via a Release Pipeline, is pushed into the default Component Repository. It can be used in Application Composition Projects afterwards. Besides that, additional component repositories can be registered in the design environment to re-use already existing components in Application Composition Projects. Those components can be bought or built by 3rd parties and do not necessarily need to be produced with the workbench.

Read more about Component Repositories.

You now have the option to add annotations to every modelled API in order to use the generated API specifications with IBM API Connect. IBM API Connect can be enabled for both: OpenApi 3.0 and Swagger 2.0. Once you enable this feature, necessary metadata about the API for the registration within IBM API Connect can be specified. In most cases, there is no additional data needed for registering the API in the gateway. IBM® API Connect® (official website: https://www.ibm.com/cloud/api-connect).

Read more about annotating your APIs for usage with IBM® API Connect® support.