BECS graphQL Service


This section is focused on explaining principles of using General BECS graphQL Service and its sample usage in BECS integration project, describing it in two major subsections:​​​​​​​

1 General BECS graphQL Service principle​​​​​​​
2 How to use General BECS REST API Service in the project

 

1 General BECS graphQL Service principle

1.1 What is graphQL?

graphQL is a query language for your API, and a server-side runtime for executing queries using a type system you define for your data. graphQL isn't tied to any specific database or storage engine and is instead backed by your existing code and data.

A graphQL service is created by defining types and fields on those types, then providing functions for each field on each type. For example, a graphQL service that tells you who the logged in user is (me) as well as that user's name might look like this:

type Query {

me: User

}

 

typ​​​​​​​e User {

id: ID

name: String

}

Along with functions for each field on each type:

function Query_me(request) {

return request.auth.user;

}

 

function User_name(user) {

return user.getName();

}

After a graphQL service is running (typically at a URL on a web service), it can receive graphQL queries to validate and execute. The service first checks a query to ensure it only refers to the types and fields defined, and then runs the provided functions to produce a result.

For example, the query:

{

me {

name

}

}

Could produce the following JSON result:

{

"me": {

"name": "Luke Skywalker"

}

}

1.2 What is General BECS graphQL Service?

BECS is open and very powerful platform used in wide range of industrial areas and business scenarios. To increase possibility of using BECS we hardly working also on adaptation of different standards for communication and keep the flexibility and power of BECS integration Visual Modeling unchanged.

General BECS graphQL Service layer was designed as another general way how to start integration via REST API call for any integration project (after adaptation of standard REST, SOAP and graphQL).

BECS graphQL Service is the layer for using graphQL queries to retrieve BECS enabled/integrated data from any BECS integration solution.

 

1.2.1 General BECS OData Service in closer look

Please do not forget, that BECS is driven by integration visual projects (called BECS Integration Project or BECS IP). The major reason of adapting graphQL Service layer is to enable using of any standard BECS IP also via graphQL channel (request/response).

This will allow to integrate with any graphQL compliant system easily and use full power of BECS projects and connectors as well.

 

1.2.2 General architecture of BECS graphQL Service

In following picture, you can see the global architecture of BECS graphQL Service and its cooperation with standard BECS IP. Schema shows standard flow for graphQL requestor:

 

1​​​​​​​.2.2.1 Execution steps for standard graphQL interaction

Following picture in previous chapter the execution flows can be described:

      1. graphQL caller is querying BECS graphQL server with well formatted graphQL query
      2. ------------------------------------ BECS graphQL Server --------------------------------------------------------------
      3. BECS graphQL server is starting to execute external query in following steps:
        1. Validation of graphQL Query syntax – in this step is validated not only graphQL syntax, but also the implemented directives (BECS graphQL server has, of course, not adapted whole graphQL syntax – see later)
      4. Successfully validated graphQL request is analyzed to retrieve:
        1. List of data tables required to update from external system
        2. Query to apply on updated Data Tables
      5. Analyzed output is then encapsulated to proper BECS TCP request and BECS Server is called
      6. -----------------------------------BECS Integration Service-----------------------------------------------------------
      7. BECS Received call into “Dispatcher Integration Project”
        1. This project will resolve what are the names of BECS DataReader integration projects assigned to Data Tables requested
        2. Dispatcher is execution all investigated BECS DataReader Integration Projects
          1. Each project is using related BECS Connectors to communicate with external systems
        3. Execution is returned to Dispatcher Integration Project to package all retrieved data from DataReader projects into one payload
      8. ----------------------------------BECS graphQL Server-----------------------------------------------------------------
      9. BECS graphQL Payload Formatter generate output in requested format (XML/json)
      10. Data are returned to called (graphQL Client)

​​​​​​​

1.2.3 Details about OData directives enabled in BECS graphQL Service

graphQL syntax supports wide range of options and directives – see www.graphQL.org. Because not all of them are relevant for BECS integration purposes in following sections you can find implemented (supported) directives in BECS graphQL server.

 

1.2.3.1 End-point description

Because graphQL is json-request syntax, we will use for all demonstrations a standard POSTMAN software (https://www.postman.com/downloads/ ):

To minimize duplicity in presenting samples will be always used endpoint:

https://uks-qa-becs.bentley.com/BECS.Odata.Translator/api/graphql 

​​​​​​​

1.2.3.2 Payload format

BECS graphQL Service supports both possible payload format (XML, JSON).

 

​​​​​​​1.2.3.2.1 Default format

Based on graphQL Service specification, graphQL always return json format (can be converted after by standard BECS tools):

Request: 

Response (json):

 

1.2.3.3 Metadata retrieve

1.2.3.3.1 Basic metadata

Standard graphQL syntax does not have any directive for metadata retrieve (similar to directive $metadata in OData…). There is expected that end user knows actual object syntax.

 

1.2.3.4 Data retrieve

1.2.3.4.1 Simple Data Request

As defined in graphQL standards also BECS graphQL Service returned data via simple query request:

Please be aware, that Service EndPoint depends on machine where the service is installed, so it needs to be changed to proper architecture every time!

Request:

Response:

 

1.2.3.4.2 Field selection

For retrieving only selected fields can be used list of requested columns in original query request.

Request:

query{Customers

{CompanyName

CustomerID

ContactName

Address

City

Phone

Fax}}​​​​​​​​​​​​​​

Response:

 

1.2.3.4.3 Data filtering Request

As defined in graphQL standards also BECS graphQL Service supports filtering by any column from table.

By placing filtering condition in brackets after the data object name, BECS graphQL Service will return filtered data.

Request:

query{Customers (where: {CustomerID: {eq: "ANATR"}})

{CompanyName

CustomerID

ContactName

Address

City

Phone

Fax}}

Response:

 

​​​​​​​1.2.3.4.4 Data linking Request

As defined in graphQL standards also BECS graphQL Service supports easy linkage of data objects.

For example, showing also all sales orders for selected customer (ANATR) use following query:

Request:

query{Customers

(where: {CustomerID: {eq: "ANATR"}}) 

{Orders {OrderId

                          CustomerID

                          EmployeeID

                          ShipName

                          ShipAddress

                          ShipCity

                          ShipCountry}}}

Response:

​​​​​​​

1.2.3.4.5 Sort Orders

As defined in graphQL standards also BECS graphQL Service supports ASC and DESC sort order options.

For example, let’s show the countries using operator (gt:”Spain”) with ascending countries and descending cities at the same time:

Request:

query{customers (where:{Country {gt: "Spain"}} order:{Country:ASC,City:DESC})

{Country

City 

CustomerID 

CompanyName}}​​​​​​​

Response:

 

1.2.3.4.6 Comparison operators

As defined in graphQL standards also BECS graphQL Service supports comparison operators’ usage: eq (=), lt (<), gt (>).

For example, let’s show also all customers where Customer ID is greater than “ANTON” use following query:

Request:

query{Customers (where:{ CustomerID: {gt: "ANTON"}})

{CompanyName

CustomerID

ContactName

Address

City

Phone

Fax}}​​​​​​​

Response:

 

1.2.3.4.7 Data Paging

To support records sub-selection can be used following directives:

1.2.3.4.7.1 Directive “first”

For returning only FIRST x records is possible to use directive “first” – for example return of first 4 Customers:

Request:

query{Customers(first: 4 

order:{ CustomerID: ASC})

{CompanyName   

CustomerID

ContactName

ContactTitle

City }}

Response:

 

1.2.3.4.7.2​​​​​​​ Directive “offset”

For starting from defined record is possible to use directive “offset” – for example return of top 4 Customers, but skip the first three (=start from fourth):

Request:

query{Customers (first: 4 offset: 3

order:{CustomerID: ASC}) 

{CompanyName 

CustomerID

ContactName

ContactTitle

City}}​​​​​​​

Response:

 

2 How to use General BECS REST API Service in the project

​​​​​​2.1 General intro

Based on general architecture diagram listed in chapter 1.2.2 General architecture of BECS graphQL Service is possible to call any BECS project.

 

2.2 Sample of calling

In this sample of calling, we used endpoint:

https://uks-dev-becs.bentley.com/BECS_Odata/api/graphql/V-301

For example, calling Equipment from SAP PM module via BECS we used:

(NOTE: SAP language table field is set in BECS project to English: SPRAS = ‘E’)

Request:

query{DATA_SAP_EQUI_Data

      {EQUNR

       EQTYP

       EQART

       INVNR

       GROES

       BRGEW

       GEWEI

       ANSDT

       ANSWT

       WAERS

       GWLDT

       HERST

       HERLD

       SERGE

       TYPBZ

       BAUJJ

       BAUMM

       OBJNR

       IWERK

       EQKTX

       TPLNR

       ABCKZ

       SWERK

       GSBER

       KOKRS

       BUKRS

       RUN_GUID}}

Response:

To call the same Equipment with related Work Orders from SAP PM module via BECS we used:

Request:

query{DATA_SAP_EQUI_Data{

      EQUNR

      EQTYP

      EQART

      INVNR

      GROES

      BRGEW

      GEWEI

      ANSDT

      ANSWT

      WAERS

      GWLDT

      HERST

      HERLD

      SERGE

      TYPBZ

      BAUJJ

      BAUMM

      OBJNR

      IWERK

      EQKTX

      TPLNR

      ABCKZ

      SWERK

      GSBER

      KOKRS

      BUKRS

      RUN_GUID

      ​​DATA_SAP_WorkOrderData{

ORDERID

        ORDER_TYPE

        CURRENCY

        CURRENCY_ISO

        ENTERED_BY

        ENTER_DATE

        SHORT_TEXT

        PLANT

        BUS_AREA

        ABCINDIC

        SORTFIELD

        PRIORITY

        EQUIPMENT

        PLANPLANT

        PLANGROUP

        MN_WK_CTR

        MN_WK_PLANT

        CUSTOMER

        MAINTPLANT

        FUNCLOC

        FINISH_DATE

        START_DATE

        NOTIF_NO

        EQUIDESCR

        FUNCLDESCR

        RUN_GUID

        RowID}}}

Response: