I. Overview
FR11.0 provides an open platform and can rely on FineReport to facilitate developers to quickly build other systems other than the central system to provide secure, flexible, standardized and effective web services
Provide a unified platform configuration to realize the management of client API rights and verification specifications.
II. Function introduction
Function entry.
After logging in to the decision-making platform as an administrator, click Manage > Open Platform to enter the function interface.
[API management]
“All APIs” are the configuration of data interaction services between third-party systems and FR.
The left side of the interface is the grouping, which is to manage the grouping of service APIs. The system has built-in many common groups.
Users can add, edit, and delete management operations on groups. Editing and deleting cannot operate on built-in groups.
After selecting a group, the right side of the interface displays the list of service APIs under the group, and the system has built-in many commonly used service APIs.
Users can add, edit, disable, delete individually, delete in batches, and change groups of service APIs.
Note: Built-in groups cannot be edited and deleted.
[Application Management]
Provide a pair of ID and key for each application to use in the authentication operation of the API.
The open platform supports the management operations of adding, editing, copying, disabling, deleting individually, and deleting in batches.
Application Settings supports customizing [Application Name], [Application Description] and [Alternative Authentication] to distinguish different applications.
[App ID] and [Key] cannot be customized and edited, and are automatically generated after adding an app.
Edit operations also support reset key operations.
[Authentication method]
The authentication method provides relevant security guarantees for external services. The open platform has three default authentication methods, and users are also allowed to expand by themselves.
Users can add, edit, disable, individually delete, and batch delete management operations for authentication methods.
The [Authentication Name] and [Authentication Description] in the authentication mode setting item can be customized, which is convenient for users to distinguish by themselves.
[API class] in the authentication method setting item is an example object of the authentication API that we need to implement (the same class can be changed into multiple authentication methods by changing the configuration).
[Configuration] in the authentication mode setting item is some fixed configuration required for this authentication. For example, digest signature authentication needs to define [Digest Algorithm] and [Validity Period]. The configuration can be set as an encryption item, and the encrypted information cannot be saved after being saved. Read from the foreground.
Built-in authentication method.
[Self-issued token authentication]
This authentication is naturally supported by all application interfaces, whether you choose an alternative authentication or not, this method is supported.
[Self-signed token authentication] is the way to call the service through access_token, you need to use the client ID and key to obtain the access_token.
The application uses application D and the key to obtain the token request address: $HOST/sp/client/api/token
Parameters: client_id = application ID secret = key Parameters can be written in Query or Header
Use the parameter client_token={access_token} to access the specific API
[AKSK direct authentication]
The [AKSK direct authentication] method is to use the client ID and key as the authentication basis to directly call the service. For security reasons, this method is not recommended and does not require configuration items. This authentication cannot be edited.
That is, you can directly access the application by adding client_id={application ID} secret={key} in the request header
[Digest signature authentication]
The method is to use the digest algorithm (such as SM3/MD5/SHA256) to sign the client ID, key and timestamp when the token authentication cannot be used. Authenticate. It is recommended to use this authentication method, which is relatively safe.
[Signature] in [Digest Signature Authentication] = digest algorithm (application ID+key+timestamp)+timestamp. For example: [client_id = 203bc7b8db1d423fb55824150327ef98, secret = 98ffd41b86db4868a6875f57e6974bbc, timestamp = 1600166180321, configuration signature algorithm MD5, and the timeout is 300 seconds] -> [Signature = MD5 (client_id + secret + timestamp) + timestamp = EE6E14BCEC5724C3BC6FC08AFC5C2B111600166180321]
[National Secret SM2 Signature Authentication]
Use the national secret SM2 ellipse algorithm for encryption and decryption, and use the standard ellipse parameter signature_sign_=sm2(clientId+secret+timestamp),
Configuration item priKey=private key timeout=timeout time (seconds)
API settings.
[API name] and [API description] can be customized arbitrarily, which is convenient for users to distinguish by themselves.
[API class] points to the specific implementation of our API service.
[API path] and [API method] indicate the path and method of calling this API in the http request. Do not add / in front of the path. The [API path] of the newly added API can also be customized by the user (be careful not to be the same as the path of the existing API).
Actual request address: $HOST/sp/client/api/{API path}. Assuming $HOST = http://localhost:8075/webroot/decision , the request address is http://localhost:8075/webroot/decision/sp/client/api/{API path}.
[Configuration] is the configuration information we need to initialize this service.
Note: The built-in API part cannot be edited, even if it can be edited, it will be restored after restarting.
[Client Permissions]
For non-public APIs, all calls require permission verification, so the scope of interfaces that can be called by different applications in different scenarios must be different, and we can assign them in this page (public APIs can be called at will not bound here)
Note: There is currently no grouping permission, that is, even if a certain grouping permission is turned on, it is essentially just assigning the permission of the API under the current group to a certain client. If there is a subsequent API grouping change, or the If the grouping API is added, the permissions will not change.
[Request log]
On this page, you can view the request frequency of the API, and you can view the detailed records of API requests.
III. Invocation example
After configuring the permissions, you can call the api interface
1. SQL Data Services
This demo example is used to show us the simplest scenario of converting SQL into a data service for use by third parties
The interface instance we need to use is: [demo]Sql data service
Contains two configuration items:
connection: The name of the data source connection that SQL is running on (such as FRDemo)
sql: The SQL of the data source
This interface is mainly used to provide some basic and simple data services to the outside world. It does not depend on templates at all, as long as you can write SQL.
For example the following test example:
Data Source Connection = FRDemo SQL = SELECT * FROM `Sales_Volume` where region = '${region}'
In this query we use a parameter region
Call it and see [two ways to pass parameters]
2. Template dataset data service
This demo example is used to show us how the dataset data in the template we have prepared can be provided to third parties.
The interface instance we need to use is: report dataset service
Contains two configuration items:
report: the source of the dataset (relative to reportlets)
dsName: the name of the dataset
This interface is mainly used for some data sets that have been prepared in the template. The third party needs to use the corresponding data, or the data source is not SQL data set data, or other data services that are not suitable for directly developing source data connections to third parties.
For example the following test example:
Template Path = GettingStarter.cpt
Dataset Name = ds1
In this query we use a parameter region
Call it and see [two ways to pass parameters]
3. Data entrt API call
The demo of filling in the interface is mainly used to show how we can use templates to simply implement when we want to provide business services such as data entry/approval to third parties.
First, it needs to use the interface instance we developed: com.tptj.plugin.hg.client.center.api.data.WriteReport
Two configuration items are supported in the configuration
report : the path to a report template (relative to the reportlets directory)
sheet: [Optional] A specific sheet name that needs to be executed corresponds to the filling business in the template filling attribute of the sheet. [If this parameter is not filled in, the reporting business in the template reporting properties of all sheets will be executed].
Note: This report will not trigger JS related events!
Note: Here we use the body parameter, which can be passed directly through the URL or through the body of the request (only if the service is invoked through the interface)
If the body of the http request is a json, then there are two kinds of references in the calculated report
1. Get the entire json string directly through the parameter name of $body or ${body}
2. If it is a body with a structure of { key1:xxxx,key2:ffffff,...,keyN:fsss}, you can also use these parameters in the report directly through $key1, $key2,....$keyN
4. Simple report determinant data service
This demo example is used to show us that for some data that cannot be easily extracted with a single data set, the data service can be output in the form of a simple report.
The interface instance we need to use is: com.tptj.plugin.hg.client.center.api.data.GetListByReport
Contains two configuration items:
report: report path of the data source (relative to reportlets)
tag: sheet name of the data source
This interface is mainly used for some datasets that have been prepared in the template. The third party needs to use the corresponding data, or the data source is not SQL dataset data, or other data services that are not suitable for directly developing source data connections to third parties.
For example the following test example:
template path = WorkBook12.cpt
sheet name = sheet1
In this query we use a parameter region
Implemented by associating two datasets
The configuration details of the demo interface we defined are as follows
The actual test effect is as follows [two ways to pass parameters]
Special note: This is not a real general interface implementation. If you want to use this interface instance, the template you make must meet the following restrictions
Only supports pure data tables
At present, a sheet is simply divided into the following situations
Data row: View from top to bottom, row by row from left to right, and find the first row with a "downward expansion" cell that is not hidden in the row where the cell is located as the starting row of data. Everything below is simply considered to be the data area to be output (so we are limited to only one data area in a sheet)
Header row: In all rows before the data row, if the row has only one grid value and the row is not hidden, the row is used as the header row. There can be multiple header lines, and the output order is sorted by line number (the header is not output in the detailed data)
List header row: In all the rows before the data row, if the row has more than one grid value and the row is not hidden, the row is used as the list header row. There can be multi-level column headers, but at present the column header of each column only takes the value of the column header cell closest to the data row as the column header.
Empty lines: All lines with a height equal to 0, or a whole line with no data. Blank lines are not output
Empty column: The column width is equal to 0, or the value of the column header for this column is empty. Empty columns are not output
Data for merged rows is output at the smallest merged row granularity.
Note: Do not use complex or large data volume templates
5. Simple report grouped data service
This demo example is used to show us that for some data that cannot be easily extracted with a single data set, the data service can be output in the form of a simple report.
The interface instance we need to use is: report data grouping service
Contains two configuration items:
report: report path of the data source (relative to reportlets)
tag: sheet name of the data source
For example the following test example:
template path = WorkBook12.cpt
sheet name = sheet1
In this query we use a parameter region
Implemented by associating two datasets
The configuration details of the demo interface we defined are as follows
The actual test effect is as follows [two ways to pass parameters]
Special note: This is not a real general interface implementation. If you want to use this interface instance, the template you make must meet certain restrictions, which are the same as the simple report determinant data service.
Note: Do not use complex or large data volume templates
Some APIs currently open:
Platform related
Custom development example - custom authentication method and API
Application scenario: The built-in authentication method or API is not enough to meet the business needs, and it is hoped that a custom developed authentication method or API can be added.
Example code and description: jee/open-client-demo: Open platform sub-plugin demo - open-client-demo - FanRuan third-party plug-in repository (fanruan.com)
Note: This example is a custom development example, for reference only. Users can refer to the relevant logic to develop by themselves. If you need official developers to do relevant custom development, please contact the corresponding sales manager for further consultation.
