Yaml

来源：互联网发布：黑客编程入门3下载编辑：程序博客网时间：2024/06/09 23:56

Project Name

GTC V3 GBL Build P0049752

Project No.

P0049752

Document Owner:

S02-04 CitiPlanner SDT Team

Rainbow Technical Design (TD) – S02-04 CitiPlanner

(High Level Design)

Assumptions, Constraints,and Decisions

Technical Approach

Database Design / Layout

Design Considerations

This page displaysthe U.S. Export Notice. Do NOT delete.

Table of Contents

DocumentChange Controliii

Template Introduction and Instruction.4

Review and Approval Table.5

1 Assumptions, Constraints andDecisions. 6

1.1 Assumptions(Required)6

1.2 Constraints(Required)6

1.3 Decisions (Required)6

2 Technical Approach(Required)7

2.1 Online System Interaction Diagram. 7

2.1.1 Exception Flow. 7

2.2 Batch System Interaction Diagram. 8

2.2.1 Exception Flow. 8

3 Database Design / Layout(Required)9

4 Design Considerations(Required)10

4.1 Design Considerationsfor Non-Functional Requirements.10

4.2 Internationalization,Localization, and Legal/Regulatory/Cultural Impacts.10

5 High Level to DetailedDesigns Correlation (Required)11

User Stories NOT impacting the Tech Design – High Level.12

6 Integration Design(Required)13

6.1 CitiplannerOnline Functionality WorkFlow Diagram.13

6.1.1 AffordabilityAssessment - HongKong (STORY ID -508538)13

6.1.2 Customer Disclosure/Declaration (STORY ID -508555)20

6.1.3 Notice toCustomer/Bank Disclosure (STORY ID - 508553)23

6.1.4 CertificationChecks (STORY ID - 508528)26

6.1.5 Special Transaction Type (STORY ID - 508544)30

6.1.6 Risk Profile and K&E Check (STORY ID - 508523)35

6.1.7 Iwish to receive no advice from Citibank (STORY ID - 508551)38

6.2 Product Processor(EBS/ECS/TPS)39

6.2.1 SystemName, Purpose and Scope (Required)40

6.2.2 SystemLogic Flowchart40

6.2.3 ProcessFlow (Required)40

6.2.4 DataPersistence. 40

6.2.5 DataConversion (i.e. ETL: Extract, Translate, Load)40

6.3 Batch Interfaces. 40

6.3.1 InterfaceLayout Definition. 40

6.3.2 InterfaceConfiguration Definition. 40

6.4 Data Conversion(i.e. ETL: Extract, Translate, Load)40

7 Additional Detailed DesignActivities. 41

7.1 ProgrammingLanguages and Standards. 41

7.2 Design Rules. 41

7.3 Internet / IntranetManagement. 41

7.4 List of Components. 41

7.5 List of RecompilesRequired. 41

7.6 Copybook Change. 41

7.7 File Changes. 41

7.8 Table Changes. 41

7.9 JCL / PROC / CARDChanges. 41

7.10 MAP (BMS) Changes. 42

7.11 SCHEDULING (e.g. COBprocedure impacts)42

7.12 Reports and ErrorFiles Generated. 42

7.13 Report Layouts. 42

7.14 Letters. 42

7.15 Statements. 42

7.16 Data Dictionary. 42

7.17 Sample Maps. 42

7.18 Additional FlowDiagrams. 42

7.19 References to MakeFiles. 42

7.20 Glossary. 43

7.21 Appendix. 43

7.21.1 J2EE action. 43

7.21.2 TIBCO operation. 44

8 Additional Technical DesignDeliverables. 47

Review andApproval Table

Prepared By:

Name:

Silver

Date:

22-jul-2015

REVIEW

Reviewed By:

Name:

Date:

Reviewed By:

Name:

Date:

Reviewed By:

Name:

Date:

Reviewed By:

Name:

Date:

APPROVAL

Approved By:

Name:

Date:

Approved By:

Name:

Date:

Approved By:

Name:

Date:

Approved By:

Name:

Date:

1 编写yaml格式RESTFulAPI

1.1 所需资源工具

IDE

STS

Swagger Editor

在线编辑和实时展现yaml工具

http://editor.swagger.io/#/

Swagger UI

最终显示RESTFul API工具

https://github.com/swagger-api/swagger-ui

Tomcat

本地测试用

6或7版本

1.2 文档描述内容

· Yaml格式文档简介

· 本地本地IDE项目集成Swagger UI, 并打成war包部署, 提供访问显示API

· 例子分析 MyGoal …

2 RESTFulAPI Yaml格式文档简介

2.1 简介

2.1.1 语法

yaml文档使用空白符缩进来表示层级关系

主要语法两种

“:” 表示Map键值对分隔符 “:”后面跟一个空格

图1

“-” 表示Sequence里的项 “-”后面跟一个空格

图2

2.1.2 编写yaml注意事项

编写Yaml必须使用一个或多个空格进行缩进，不能使用制表符(Tab键)，两级之间使用两个空格缩进。

Yaml中添加注释是通过井字符(#)

2.1.3 基本数据类型

图3

2.2 Yaml格式API必要固定域

名称

类型

描述

swagger

string

必需，指明Swagger版本，值为2.0

info

Object

必需，API的元数据，通常需要三个子域 tile, description, version

host

string

API的server ip地址，如 127.0.0.1

basePath

string

API的基本路经，值必须以斜线开头，如 /v1

schemes

[string]

指定API的请求协议，如https

produces

[string]

描述API信息内容类型，如application/json

paths

Object

必需，指定API提供的操作，内容包括URI，请求方式，请求参数和返回值等

definitions

Object

定义API提供的操作所需的参数和返回对象数据类型，非基本数据类型

parameters

Object

定义一个API操作所需的参数

responses

Object

必需,定义一个API操作返回值

2.2.1 一个API操作所需子域 paths

如图

图4

2.2.1.1 第二层指明操作的URI 路径，必须以斜线开头如 /products

2.2.1.1.1 第三层指明执行这个API操作的请求方式如 get / put / post / delete

一个URI可以有多个请求方式，不同请求方式属同一级，且需分别指明请求参数和返回值等，具体视文档而定

2.2.1.1.1.1 第四层指明这个API操作的请求参数和返回值等信息

这一层必要的子域

summary

这个操作的总结参考图4

description

这个操作的详细描述参考图4

parameters

这个操作的请求参数参考图4

responses

必需，这个操作的返回值参考图4

2.2.2 请求参数信息parameters

固定域

name

string

必需，参数名，大小写敏感

string

必需，参数位置，有 header,body,query,path,formData

description

string

这个参数的简单描述

required

boolean

指明这个参数是否必须的，默认值是 false

schema

Schema Object

只有当参数位置在body时才有，必需的，用来指明body的参数类型，在后面的definitions里定义，参考图4

type

string

当参数位置不在body时，参数类型，必需的

format

strinig

扩展格式，参考图3

一个API操作可以有多个参数，但是只能由一个位置在body的参数。

参考文档 https://github.com/swagger-api/swagger-spec/blob/master/versions/2.0.md

2.2.3 返回值信息responses

固定域

description

string

返回值描述

schema

Schema Object

指定返回值的类型，在后面的definitions里定义

每个API操作可有多个response,是文档而定

每个response上一层要指明返回的状态码, 如 200/400/403/500等

参考文档 https://github.com/swagger-api/swagger-spec/blob/master/versions/2.0.md

2.2.4 数据类型定义 definitions

如图

图5

2.2.4.1 第二层根据每个parameter和response中schema子域的定义,，每种数据类型都作为一个definition(相当于Object)进行定义。可以有多个definition,如viewGoalLanding，参考图5

2.2.4.1.1 第三层指明这个definition的属性信息和需要的属性 properties & required

每个属性固定域

description

string

属性描述

type

string

属性类型，基本类型或对象

example

string

例子，属性是基本类型是设置

items

Object

如果属性类型是个array,指定一个数据类型

当definition的属性是一个Map 时，这个属性只需下面两个子域

description

string

属性描述

$ref

string

指定一个数据类型

Yaml文档里声明的每种数据类型都要作为一个definition进行定义。

3 本地IDE项目集成Swagger UI, 并打war包部署提供访问显示API

Yaml

Review andApproval Table

1 编写yaml格式RESTFulAPI

1.1 所需资源工具

1.2 文档描述内容

2 RESTFulAPI Yaml格式文档简介