本文内容出自微软在 Build 2021 中更新的 Power Platform 学习资料: https://aka.ms/fusiondevbook
这份学习资料的主题是帮助专业开发者如何更好的与低代码开发者(公民开发者)一起协作完成应用,最终实现一个 Power Apps 与 Azure 结合的解决方案。
接下来几期我会将该资料本地化,并在过程中加入自己的理解(图片本期标题就是对内容的理解)。
本期内容总结:Fusion 开发是低代码开发人员、专业开发人员和其他能够对构建或使用应用起到帮助的各方人员一起协作,从而高速迭代完成应用的开发方法(这种方法可以有效避免产品经理和程序员之间的恩怨)
第一章: 什么是 Fusion 开发方式?
大家知道想要更有效率的开发应用,少不了业务需求的有效传递和理解。所以许多的应用开发实际都会提倡让最终用户去参与到整个开发过程中来。但实际情况是最终用户和开发者之间沟通会有很大障碍。
在国内这个象限可以称作程序员和产品经理之间的恩怨情仇,当产品经理向程序员提了一个需求后,程序员以为他理解了,但实际会由于双方角色的不同,导致理解方式也不一样,很容易造成最终完成的功能并不是产品经理最初提的需求。
所以如何能够将最终用户真实的需求和想法转换为开发都能正确理解的语言是应用成功的基础。而现在通过微软 Power Apps 就可以解决这个难题。
了解需求的业务用户可以通过 Power Apps 中提供的一些图形化工具拖拽生成应用界面,并利用 Power Fx 低代码公式去编写一些基本的业务逻辑。比较常见的是一些表单收集,数据显示的场景,并且还可以通过400+的预置数据连接器帮助低代码开发者快速连接到这些数据源系统中做对接,比如将 Excel 中的数据显示到画布应用中,或者通过 SQL Server 连接器操作产品数据,在应用中完成产品数据的创建,更改和搜索功能。
如果想要查看所有提供的预置连接器列表,可以访问:aka.ms/Aabvfzh
上面提到的就是低代码开发人员常见的应用创建流程,他们可以像刚才那样利用 Power Apps 去快速的满足当下的业务需求,但一旦需求变得复杂,这种方式可能就无法满足需求了。比如,你的需求是让应用和企业现有的一些系统或者数据库进行交互,而官方并没有提供符合要求的数据连接器,或者在应用中要实现很复杂的业务需求。类似这些情况就需要专业的开发者提供帮助,低代码开发者可以通过 Power Apps 完成应用的前端界面原型,而专业开发者就需要去创建自定义连接器来满足更加复杂的需求。他们可以通过创建自定义连接器来帮助 Power Apps 访问到其他的系统服务,或者实现更加复杂的需求。之后低代码开发人员再通过自定义连接器,将这些完成好的复杂业务逻辑集成到 Power Apps 应用界面中,这样整个过程低代码的开发者就不需要了解复杂逻辑是如何实现的,直接用就可以。
这里提到的自定义连接器常见作用就是让应用能够访问预置连接器之外的其他系统和服务(包括企业本地的系统)。
通常自定义连接器的创建方式是专业开发者通过把这些系统和服务的操作封装成 Web API,然后再把这些 Web API 托管成可以访问的服务,最后在 Power Apps 门户中按照步骤去将 Web API 创建成自定义连接器。
而如果开发人员使用的是 Azure,整个过程会更加简单,可以直接将开发完成的 API 托管为 Azure Web APP, 然后通过 Azure API 管理服务直接导出成自定义连接器。
回到我们第一章的话题 Fusion 开发, Fusion 开发简单理解就是将低代码开发人员、专业开发人员和其他能够对构建或使用应用起到帮助的各方人员结合在一起,一起协作来完成应用的开发方法。低代码开发者可以通过 Power Apps 去构建应用前端来快速表达业务的实际需求,并且和专业开发者一起合作来完成复杂的业务逻辑。而最终用户可以帮忙提供反馈意见。这样整个过程就形成了一个可以高速迭代的闭环。
Gartner 将使用 Fusion 开发方法的团队称为 “fusion teams”,原文是这样描述的“distributed and multidisciplinary digital business teams that blend technology and other types of domain expertise. At least 84% of companies and 59% of government entities have fusion teams.“( 出自 2019 Gartner Digital Business Teams Survey)
关于更多的 Fusion 开发流程以及它是如何缩短整个开发周期的详细介绍可以阅读:aka.ms/Aabvfzj