38-尚硅谷-支付宝支付-定时查单-订单未支付

我们刚才完成了我们整个这个业务流程当中的第一个分支，如果订单未创建，则更新商户端订单状态，那么接下来呢，我们来看第二个分支，好，我们先做这个啊，把它放到第二个里面来，如果订单未支付，则调用关单接口关闭订单，并更新商户端的订单状态，那么首先呢，我们得判断一下这个订单的状态，所以呢，我们得先把伪造的这个结果呢，给它解析出来，那么我们来看一下查单接口，最后得到result的result，它是什么样的一个数据格式，我们找到最后的。响应参数这一部分。那么这是我们的响应示例，响应事例当中呢，我们会得到一个Jason，那这个Jason呢，是一个嵌套的数据哈，所以呢，我们整个呢，造的就是这样的一个字符串，那我们呢，经过这次类型转换之后呢，我们会得到一个键值，对这个键呢，就是阿里pay trade的query response，那值呢，是下面的这个Jason字串啊这个Jason字符串里面呢，又包含很多子节点哈，好，那现在呢，我们用这次呢对它做一个数据类型的转换，所以呢，在这个位置我们来解析刚才我们的结果。

好，那么我们先创建一个G，利用这个Jason呢？我们对返回的Jason形式的字符串呢，做一个数据类型的转换，我们用from Jason。哈西map.class我们把它转成哈西map，那么我们这个哈西map呢，我们给它命一个名字吧，就叫做result map，好当我们的Jason中串结果它是一个嵌套Jason的形式的时候呢，Jason它会把里面的子节点转换成一个link的去，所以呢，我们在这个地方，你们知道里面的反馈结果呢，它会是一个link去麦。

因为它里面又是一系列的建筑队，是不是，那么如果又是一系列的建队的话，我们的这次就会默认情况下把这个建筑队呢，转换成这样的一个数据类型啊好，那接下来呢，我们就可以从result map当中呢，获取到我们的响应结果了，这个响应结果我们要看一下文档，它的键呢叫阿里配trade的快response。我们把它粘到这个位置好，我们这样的话就会得到一个link的trade map，那么我们从link tree map里面呢，再获取到我们需要的订单状态，这个订单状态呢，它的。

名字呢，就叫做。Status，我们把它复制过来。好，那么我们通过这种方式呢，就可以获取到我们的订单状态了，而且这个订单状态呢，它是一个字符串类型的哈，所以呢，我们给它转换成字符串类型。好，这面也是一样的，把它转换成字串类型里面，我们重命名一下叫trade status，接下来呢，我们对trade status呢进行一个判断，那么如何进行判断呢？参考之前的微信配service m PL，我们之前微信配呢，有一个微信trade statuss啊这个里面呢，定义了一系列的微信端的支付数据的订单状态，那么我们呢，在我们的应用程序当中呢，也。

参考着他创建一个支付宝的订单状态，那我们这个订单状态呢，指的是远程服务器的支付订单的状态啊，和我们本地的这个业务服务器的业务订单的状态，大家要区分开好，我们来创建支付宝的这个订单状态。我们把这个微信的复制一下，给它改一下，改成阿里he state。那么这个里面的几个状态呢，它和微信端生成的这个字符串所返回的字符串呢，是不太一样的，我们必须得查看支付宝的。文档。我们找一下status status这个订单状态搜一下吧。我们搜索trades。好，这边呢，如果是未支付的话，就是wait by pay。所以呢，我们在刚才阿里配trade state这个地方位置去大家配，接下来呢，是。

交易超时关闭啊好，我们把它复制过来。然后呢，是。支付成功。好，这个里面还有一个转入退款，我们到时候做退款的时候再来去修改它。然后这边呢，还有一个交易结束不可退款，那和我们的应用程序没有关系哈，因为我们的是可以退款的，所以就判断所status就可以了，那所以呢，现在我们的支付宝端的订单状态的这个枚举呢，我们已经初步的完成了，我们呢，在我们的业务当中，对这个枚举阿里pay trade state，如果是未支付的话，那么也就是这个no pay哈，第2GET type equals和刚才我们获取出来的trade status呢进行比较，如果他们两个比较成功了，就说明我们的订单未知词付。

好，那么我们把订单号呢打印出来，接下来呢，如果订单未支付，则调用关单接口，也就是我们现在要做的这件事情。并更新商户端的订单状态，所以呢，我们先来调用关键接口this掉啊，Close order，我们把order number传递进去，然后呢，我们来更新商户端的订单状态，所以呢，就是order INF for service表update status by order number，传递一个order number，接下来呢，再传递一个order status，我们选择的是超时已关闭close，这样的话呢，这个业务方法呢，我们就完成了，好，那么在重新启动服务器之前呢，我们先来创建一个已创建但未支付的订单啊，要不然我们启动服务器之后呢，我们没有办法控制我们的定时任务什么时候执行了，就万一我们的订单刚刚创建定时任务就执行了，我们呢，就不能在测试的过程当中完整的观察我们订单的这个状态了哈，所以，所以呢，我们先来发起一笔支付。

那么在我们的课程购买这个页面当中呢，我们这次买一个大数据的课程，我们选择支付宝确认支付，我们先来进行扫码啊。让这个订单呢，是一个未支付的订单，并且呢，这个订单呢，在支付宝端已经创建出来了，好来点击扫一扫。好，现在我们这个订单呢，就是一笔未支付，并且已经在支付宝端创建出来的订单了，那么接下来呢，我们的应用程序的这一部分功能，如果正常的执行了的话，那他就会查询到这笔订单，核实到这笔未支付的订单。

并且呢，对我们的远程的订单呢，进行一个关单操作，然后呢，更新我们本地订单的商户订单状态，那么我们先来对我们的远程的订单呢，进行一个查单操作啊，看一看它现在是不是一个未支付的状态，所以呢，我们先打开之前我们的W。还是用一下之前我们的查单接口，我们来看一下我们当前的这笔订单，他的目前为止的状态呢，是一个未支付的状态，那么这是在我们本地订单的一个状态哈，那么接下来呢，我们再查询一下远程的订单状态，我们找到刚才他的这个订单号啊，就是他的订单号053。

我们搜索一下他远程的订单状态。在这个位置也是一个等待用户付款的状态，也就是说远程在支付宝端的这个支付订单的状态呢，也是一个用户未支付的状态，所以接下来呢，我们来将我们的应用程序呢进行重启，然后呢，让我们的定时任务进行启动，启动完成之后呢，看一看我们的查单功能呢，能不能查询到这笔超时未支付的订单，并且呢，把它自动的关闭掉，好，所以呢，我们来重启一下我们的服务器。定时任务当中设置的呢，是从第零秒开始执行，每隔30秒执行一次，好，那么我们会发现呢，刚才我们的这个定时任务呢，是从。

43分30秒哈，开始执行的，每隔30秒执行一次嘛，所以我们呢，可以等待零秒或者是30秒，对第30秒的时候呢，他被执行了，然后被执行的过程当中呢，他查询到了我们的系统当中有一个没有支付的大数据订单，那么这是在我们本地没支付，所以呢，他就去我们的支付宝的服务器端呢，进行订单状态的一个核实，那么先进行了一个查单接口的调用，调用完成之后呢，我们查询到了这个订单。查询到这笔订单之后呢，我们会发现我们这笔订单的返回结果就是阿里配的que response当中的一个支付状态，在这个位置，那么就是wait buy pay，也就是在远程的支付宝的服务器上呢，这笔订单的支付状态呢，也是一个未支付的状态。那么接下来呢，我们就要。

执行这个核实订单未支付的这样的一个代码了，在这个位置哈，我们查询到了他确实是一个未支付的状态，所以呢就打印了这个核实订单未支付，然后接下来呢，就调用了我们的关单接口，那么在支付宝端呢，这笔订单呢就会被关闭好，然后在接下来呢，更新了我们商户端的订单状态，所以呢，在这面我们订单状态呢，变成了超时已关闭好，那这样的话呢，我们整个的测试呢就完成了，那我们先来看一下我们当前的业务系统当中，是不是订单呢已经变成了超时已关闭。确实是这样的，我们再来看一下支付宝端这个订单呢，它的状态是不是也变成了一个关单的一个状态，我们点击查询，然后我们来看一下它后面的订单状态。

我们会发现呢，也是一个trade cost，所以呢，这样的话就完成了我们当前的这个业务代码的一个测试，啊，我们的测试呢是成功的。