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
Table of Contents
Template Introduction and Instruction. 4
1 Assumptions, Constraints andDecisions. 6
2 Technical Approach(Required)7
2.1 Online System Interaction Diagram. 7
2.2 Batch System Interaction Diagram. 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.3 ProcessFlow (Required)40
6.2.5 DataConversion (i.e. ETL: Extract, Translate, Load)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.3 Internet / IntranetManagement. 41
7.5 List of RecompilesRequired. 41
7.9 JCL / PROC / CARDChanges. 41
7.11 SCHEDULING (e.g. COBprocedure impacts)42
7.12 Reports and ErrorFiles Generated. 42
7.18 Additional FlowDiagrams. 42
7.19 References to MakeFiles. 42
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操作返回值 |
tags | [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 |
tags | 这个操作所属类别 参考图4 |
2.2.2 请求参数信息parameters
固定域
name | string | 必需,参数名,大小写敏感 |
in | 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
3.1 下载资源Swagger UI
3.1.1 下载dist文件夹,路径 https://github.com/swagger-api/swagger-ui/tree/master/dist
3.2 创建项目,集成SwaggerUI
3.2.1 创建创建一个web项目, 将下载的dist文件夹里的内容拷贝放到项目的webcontent里,
目录如下图:
3.2.2 修改index.xml文件
修改url的值, 指向编写好的API文件路径
如图
3.3 部署项目,本地访问
3.3.1 将项目部署到本地服务器 (Tomcat),并启动访问
效果如图:
4 例子分析 MyGoal案例
4.1
5 参考资料