Integrating microservices

Support
#1

HI,
I’m evaluating Cuba Platform and I’m trying to understand how complex is to use the platform with rest services offered from the microservices.
I want to avoid to directly access the internal schemas. Furthermore, other microservices are just DB less. Some of the interfaces are not still specified, what’s the best way to define them to be consumed by Cuba?
Can you give me some hints?

P.S.
The largest part of the application can be managed with standard CRUD on Relational DBMS.
Some of the actions and Data sources are implemented in a cluster of Microservices.

3 Likes
#2

Hi,

i’m not sure i fully understand your question. So i will answer the question that i interpreted - which is “how can i consume REST (or other) endpoints from other (micro-)services so that i can integrate with them”?

As this implies that you are willing to write source code that consumes a service through HTTP within your CUBA application, the answer is: It is as easy or as problematic as with any other Java (even any other) application. How hard it is to integrate with a certain other application (which a micro service just is at the end of the day) depends heavily on the actual endpoint.

Here are some examples of doing HTTP calls in CUBA:

  • Aleksey created an example with a public HTTP API call that displays information from a HTTP service (currencies) in a CUBA table - aleksey-stukalov/custom-datasource
  • i created an example on how to integrate with the Xero API - which, instead of using plain HTTP java libraries, uses a “offical” library from the producer of the service that encapulates the HTTP communication more or less: mariodavid/cuba-example-xero-api-integration

Basically what it boils down to is the following two factors

  • how complicated is the HTTP API of the service (using SOAP / REST, authentication through OAuth or Basic Auth or none etc.)
  • how complicated is the HTTP java library that you are using (it can be as simple as “http://google.com”.toURL().text or as complicated as using Apache HttpComponents java library through a proxy with custom TLS certificates configured correctly in order to send a multi part form with a file Base64 encoded

When you say some APIs are not yet specified, you might want to have a look at REST resource naming since this is somewhat a industry standard (although REST does not say anything about resource names) at least from a convention point of view.

In order to get you more concrete answers, it would be good if you could specify your questions a little more precise. I hope i could help you with this general claims.

Bye
Mario

2 Likes
#3

Let me also mention the following feature of the platform which can be useful in the context of consuming external services:

  • Data model can contain persistent (stored in a relational DB) or non-persistent entities, and both types of entities are equal from the presentation tier perspective - you can display and edit them in data-aware visual components.

  • A non-persistent entity can belong to a custom DataStore and can be routed to/from this data store by DataManager.

It means that you could create a DataStore implementation working with your micro-service to load data and convert it to entity instances and to save data from the entities back to the service. If you manage to do this, your client code will work uniformly with all your data regardless of whether it is stored in the database or comes from micro-services.

3 Likes
#4

Thank you.
this answers to my (yes was not so clear) question.

#5

Hello guys,

we are actually evaluating the CUBA as a UI platform for our enterprise Apps. In general, we have a number of highly automated workflows, but we still require a number of ‘Apps’ that are capable of displaying and mutating business states by ‘human’ users.

We also adapted the ‘microservices’ pattern, where a number of back-office App ‘owns’ a context over a dedicated Domain Model (DM) and business logic. The back-office Apps are structured as follows:

i) API (we are using a RPC-based API using gRPC and proto3 as IDL)

ii) The business logic is implemented in Java

iii) App ‘state’ is stored in a relational data model using JOOQ

The question is now if CUBA is capable to deal (read AND write) with the RPC based back-office API. As we understood CUBA offers an ‘AbstractNotPersistentEntity’ approach, where the corresponding entity is programmatically created/mapped using arbitrary API
calls.

In summary, the questions we still have are:

  1. How does CUBA support ‘write’ API calls? If a property of an AbstractNotPersistentEntity is mutated - how does CUBA trigger the state change?

  2. CUBA offers a lot of standard functionalities like security, traceability of user actions, etc. Are this features available even when AbstractNotPersistentEntities are involved?

Thank you.

Best Regards,
J. Jetmar

#6

Hi Jiri,

You are right, non-persistent entities can be used to represent data stored in external systems. In fact, the CUBA front-end and many middleware mechanisms don’t care whether an entity is persistent or not, and non-persistent entities are first-class citizens in the data model. Moreover, there can be references between persistent and non-persistent entities.

The [data stores](Data Stores - CUBA Platform. Developer’s Manual) mechanism allows you to implement a logic for loading and saving non-persistent entities in external systems. So you can integrate data from external systems into your data model seamlessly.

Now about your questions.

If a property of an AbstractNotPersistentEntity is mutated - how does CUBA trigger the state change?

All entities including non-persistent can have listeners that are notified when a setter or setValue(property, value) method is invoked. When an entity is owned by a [datasource](Datasources - CUBA Platform. Developer’s Manual) on the client tier, the datasource listens to changes in properties and sends modified instances to the middleware. It works the same for persistent and non-persistent entities. As I mentioned earlier, the client tier is persistence-agnostic.

CUBA offers a lot of standard functionalities like security, traceability of user actions, etc. Are this features available even when AbstractNotPersistentEntities are involved?

Not all of them work for non-persistent entities:

1 Like