CN111324780A - 产品数据的存储方法、发送方法、装置及存储介质 - Google Patents

产品数据的存储方法、发送方法、装置及存储介质 Download PDF

Info

Publication number
CN111324780A
CN111324780A CN202010130581.6A CN202010130581A CN111324780A CN 111324780 A CN111324780 A CN 111324780A CN 202010130581 A CN202010130581 A CN 202010130581A CN 111324780 A CN111324780 A CN 111324780A
Authority
CN
China
Prior art keywords
product
product data
full
request message
interface
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
CN202010130581.6A
Other languages
English (en)
Inventor
郑含
王昆鹏
陈小龙
柳春
邢月鲜
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Sankuai Online Technology Co Ltd
Original Assignee
Beijing Sankuai Online Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Sankuai Online Technology Co Ltd filed Critical Beijing Sankuai Online Technology Co Ltd
Priority to CN202010130581.6A priority Critical patent/CN111324780A/zh
Publication of CN111324780A publication Critical patent/CN111324780A/zh
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90Details of database functions independent of the retrieved data types
    • G06F16/901Indexing; Data structures therefor; Storage structures
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management
    • G06Q10/02Reservations, e.g. for tickets, services or events
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00Systems or methods specially adapted for specific business sectors, e.g. utilities or tourism
    • G06Q50/10Services
    • G06Q50/14Travel agencies
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/51Discovery or management thereof, e.g. service location protocol [SLP] or web services

Abstract

本申请公开了一种产品数据的存储方法、发送方法、装置及存储介质,属于计算机领域。该存储方法通过产品接口向后台系统发送请求报文,接收后台系统发送的响应报文,响应报文中包括全量产品数据,将全量产品数据存储至数据库中。该方法通过设置的统一预订设备将后台系统中的全量产品数据存储至数据库中,实现了不论系统商有多少个,也不论系统商是否发生了更换,均使用产品接口来获取全量产品数据,进而将全量产品数据沉淀在数据库中,供景区工作人员的分析和使用,提高了景区自身的数据中心的数据使用率和抗风险性。

Description

产品数据的存储方法、发送方法、装置及存储介质
技术领域
本申请涉及计算机领域,特别涉及一种产品数据的存储方法、发送方法、装置及存储介质。
背景技术
景区是以旅游及相关活动为主要功能或主要功能之一的区域场所。景区中设置有基于计算机的售票系统和检票系统,简称售检票系统。
相关技术中,景区所使用的售检票系统是由系统商提供的。系统商生产和制造售检票系统,在景区的售票点设置售票系统,在景区的出入口设置检票系统,以及为景区设置数据中心。该数据中心会存储有产品数据,其中,产品是指各类门票及门票套餐。
由于不同系统商提供的数据存储能力并不一致,若景区将旧系统商A切换为新系统商B,则旧系统商A所产生的产品数据无法再继续利用。
发明内容
本申请实施例提供了一种产品数据的存储方法、发送方法、装置及存储介质,可以将采用产品接口接收到的全量产品数据存储至数据库中,不论系统商是否更换,均能够保证景区工作人员对全量产品数据的正常使用。所述技术方案如下:
根据本申请的一个方面,提供了一种产品数据的存储方法,应用于统一预订设备中,统一预订设备是位于售检票系统和后台系统之间的设备,该方法包括:
通过产品接口向后台系统发送请求报文,请求报文用于获取商家在指定时间段内的全量产品数据,产品接口适用于统一预订设备与至少两个不同的后台系统之间的信息交互,产品接口是后台系统提供的接口;
接收后台系统发送的响应报文,响应报文中包括全量产品数据;
将全量产品数据存储至数据库中。
根据本申请的另一个方面,提供了一种产品数据的发送方法,应用于后台系统中,后台系统上包括产品接口,该方法包括:
接收统一预订设备调用产品接口发送的请求报文,请求报文用于获取商家在指定时间段内的全量产品数据,产品接口适用于统一预订设备与至少两个不同的后台系统之间的信息交互,统一预订设备是位于售检票系统和后台系统之间的设备;
根据请求报文获取全量产品数据;
向统一预订设备发送包括全量产品数据的响应报文。
根据本申请的另一个方面,提供了一种产品数据的存储装置,该装置是位于售检票系统和后台系统之间的装置,该装置包括:
第一发送模块,用于通过产品接口向后台系统发送请求报文,请求报文用于获取商家在指定时间段内的全量产品数据,产品接口适用于统一预订设备与至少两个不同的后台系统之间的信息交互,产品接口是后台系统提供的接口;
第一接收模块,用于接收后台系统发送的响应报文,响应报文中包括全量产品数据;
存储模块,用于将全量产品数据存储至数据库中。
根据本申请的另一个方面,提供了一种产品数据的发送装置,应用于后台系统中,后台系统上包括产品接口,该装置包括:
第二接收模块,用于接收统一预订设备调用产品接口发送的请求报文,请求报文用于获取商家在指定时间段内的全量产品数据,产品接口适用于统一预订设备与至少两个不同的后台系统之间的信息交互,统一预订设备是位于售检票系统和后台系统之间的设备;
获取模块,用于根据请求报文获取全量产品数据;
第二发送模块,用于向统一预订设备发送包括全量产品数据的响应报文。
根据本申请的另一个方面,提供了一种产品数据的存储系统,该系统包括:统一预订设备和数据库,统一预订设备是位于售检票系统和后台系统之间的设备;
统一预订设备,用于执行如上一个方面的产品数据的存储方法,以将全量产品数据存储至数据库中;
数据库,用于存储全量产品数据。
根据本申请的另一方面,提供了一种计算机设备,上述计算机设备包括:处理器和存储器,上述存储器存储有计算机程序,上述计算机程序由上述处理器加载并执行以实现如上一个方面的产品数据的存储方法,或者,如上另一个方面的产品数据的发送方法。
根据本申请的另一方面,提供了一种计算机可读存储介质,上述计算机可读存储介质中存储有计算机程序,上述计算机程序由处理器加载并执行以实现如上一个方面的产品数据的存储方法,或者,如上另一个方面的产品数据的发送方法。
本申请实施例提供的技术方案带来的有益效果至少包括:
通过在售检票系统和后台系统之间设置统一预订设备,由统一预订设备通过产品接口向后台系统发送对全量产品数据的请求,从后台系统中获取商家在指定时间段内的全量产品数据,并将上述全量产品数据存储至数据库中,实现了不论系统商有多少个,也不论系统商是否发生了更换,均使用产品接口来获取全量产品数据,进而将全量产品数据沉淀在数据库中,供景区工作人员的分析和使用,提高了景区自身的数据中心的数据使用率和抗风险性。
附图说明
为了更清楚地说明本申请实施例中的技术方案,下面将对实施例描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1是本申请一个示例性实施例提供的计算机系统的结构框图;
图2是本申请一个示例性实施例提供的产品数据的存储方法的流程图;
图3是本申请一个示例性实施例提供的产品数据的发送方法的流程图;
图4是本申请另一个示例性实施例提供的产品数据的存储方法的流程图;
图5是本申请另一个示例性实施例提供的产品数据的存储方法的流程图;
图6是本申请一个示例性实施例提供的产品数据的存储装置的示意图;
图7是本申请一个示例性实施例提供的产品数据的发送装置的示意图;
图8是本申请一个示例性实施例提供的计算机设备的结构示意图;
图9是本申请另一个示例性实施例提供的计算机系统800的结构框图。
具体实施方式
为使本申请的目的、技术方案和优点更加清楚,下面将结合附图对本申请实施方式作进一步地详细描述。
首先对本申请涉及的几个名词进行介绍:
景区:是以旅游及相关活动为主要功能或主要功能之一的区域场所。
渠道:是用于售卖景区门票的销售渠道。按照类型划分,渠道包括:现金窗口渠道、官方网站渠道、官方移动互联网入口渠道(比如微信)、旅行社渠道、特殊团队渠道、OTA(OnlineTravelAgency,在线旅行社)、网上商店或其它渠道中的至少一种。同一个景区可以拥有多个渠道,同一个商家也可以拥有多个渠道。
系统商:用于为景区的售检票系统,提供后台服务的服务商。可选地,售检票系统中的前端和硬件设备,也可以由系统商向景区提供。
票务数据:在景区门票的售票过程和检票过程中生成的数据。票务数据包括:用户数据、订单数据、产品数据和渠道数据中的至少一种。
用户数据:与用户帐号的注册、登录和管理有关的数据。
订单数据;与门票订单的下单、核销和改签有关的数据。
产品数据:与门票产品的上架、下架、库存有关的信息;全量产品数据即指定商家的全部产品数据。
统一预订设备:是在本申请中,在售检票系统和后台系统之间新增加的设备。用于实现售检票系统和后台系统之间的报文转发,以及报文格式的统一。并且,统一预订设备还用于将后台系统中的票务数据,为景区在数据库中额外备份一份;其中,票务数据包括产品数据。
请参考图1,示出了本申请一个示例性实施例提供的计算机系统100的框图。计算机系统100包括:售检票系统120、统一预订系统140、后台系统160和数据库180。
售检票系统120是一套软件系统,可以部署在每个景区以及各个渠道。以景区1为例,在部署售检票系统120后,提供一个或多个渠道的门票售卖服务。示意性的,渠道包括:现金窗口、官网网站、官方微信公众号(一种移动互联网入口)、旅行社、特殊团队、OTA(OnlineTravelAgency,在线旅行社)或其它渠道中的至少一种。特殊团队包括:学生团队、老人团队、教师团队等。
统一预订系统140用于向售检票系统120和后台系统160提供统一形式的标准化接口,简称统一接口。该统一接口用于与售检票系统120之间收发报文,和/或,该统一接口用于与后台系统160之间收发报文。示意性的,该统一接口包括:产品接口、产品更新接口、订单相关接口、景区渠道设置接口、景区自营用户接口等。
可选地,统一预订系统140还用于在景区和后台系统160之间进行报文的路由转发,以及在渠道和后台系统之间进行报文的路由转发。示例性的,统一路由规则中包括:景区与后台系统之间的路由规则,景区与售卖渠道之间的路由规则。
后台系统160是指由售检票系统的系统商提供的计算机系统。后台系统160通过售检票系统120向景区提供售检票服务。后台系统160可以有多个。每个景区与至少一个后台系统160绑定。
数据库180用于为景区120存储票务数据。其中,票务数据包括:用户数据、订单数据、产品数据和渠道数据中的至少一种。数据库180是统一预订设备140为景区120设置的数据库。可选地,每个景区120对应各自的数据库。
示例性的,景区对应第一组织机构(比如政府),统一预订系统140对应第二组织结构(比如OTA平台商),后台系统160对应第三组织结构(比如系统商)。其中,售检票系统120和统一预订系统140均由第二组织结构提供。
在一个可能的设计中,售检票系统120发送第一报文,由统一预订系统140向后台系统160转发第一报文。在后台系统160反馈第一报文的响应报文后,由统一预订系统140将响应报文转发给售检票系统120。由统一预订系统140将第一报文或响应报文中的票务数据存储至数据库180中。
在另一个可能的设计中,由后台系统160将第二报文推送至统一预订系统140,由统一预订系统140将第二报文中的票务数据存储至数据库180中。
在本系统中,售检票系统120包括售检票系统的前端。售检票系统的前端可以是第一组织机构提供的前端,也可以是第二组织机构提供的前端,还可以是第三组织机构提供的前端。
在本系统中,统一预订系统140和后台系统160形成售检票系统120的后端。
需要说明的一点是,上述景区可以为多个,每个景区对应有自身的售检票系统。每个景区还对应有一个系统商。对于同一个景区,该景区的系统商还可能会系统商1切换为系统商2。此时,售检票系统的后台系统,也会从后台系统1切换为后台系统2。
需要说明的另一点是,由于存在多个景区的售检票系统120和/或多个系统商的后台系统160,统一预订系统140具有路由转发功能。但是在某些实施例中,比如仅有一个售检票系统120和一个后台系统160时,可以不设置统一路由设备。
需要说明的另一点是,后台系统160存储有一份原始票务数据,图1中所示的数据库是用于存储供景区使用的备份票务数据。由于备份票务数据是原始票务数据的备份,因此在理想情况下,备份票务数据与原始票务数据完全相同,或者,内容相同仅数据格式不同。
在本系统中,售检票系统120可以建立在景区服务器上,或者,可以设计为云服务形式上。
示例性的,景区1内部署有景区服务器1,系统商1为景区1建立售检票系统120,将售检票系统120部署在景区服务器1上;景区2内部署有景区服务器2,系统商1为景区2建立售检票系统120,将售检票系统部署在景区服务器2上。
示例性的,系统商2为景区3建立售检票系统120,将售检票系统120部署在云服务器上;系统商3为景区4建立售检票系统120,将售检票系统120部署在云服务器上。
售检票系统120运行在后台系统160中,各个景区或渠道可以通过浏览器形式(或应用程序的内置浏览器)来访问该售检票系统120。
请参考图2,示出了本申请的一个示例性实施例提供的产品数据的存储方法的流程图。本实施例以该方法应用于图1所示的统一预订系统140中来举例说明。该方法包括:
步骤202,统一预订设备通过产品接口向后台系统发送请求报文。
统一预订设备是位于售检票系统和后台系统之间的设备。产品接口是统一接口中的一类,即是统一预订设备和后台系统之间的一类程序接口。上述产品接口是由后台系统向统一预订设备提供的程序接口;上述产品接口适用于统一预订设备与至少两个不同的后台系统之间的信息交互。可选地,上述产品接口适用于统一预订设备向至少两个不同的后台系统发送请求报文。
在售检票系统的运行过程中,在显示设备上展示商家在指定时间段内的全量产品数据,上述全量产品数据由后台系统提供,统一预订设备通过产品接口向后台系统发送请求报文,该请求报文用于向后台系统请求获取商家在指定时间段内的全量产品数据。需要说明的是,针对于景区,上述产品是指各类门票、门票套餐等。
可选地,统一预订设备周期性调用产品接口向后台系统发送请求报文。商家会不定时地调整产品,或上线新产品,或下线旧产品,或更新产品数据;相应地,后台系统的全量产品数据不断更新,统一预订设备也需要针对后台系统中全量产品数据的更新,更新数据库中存储的全量产品数据,因此,统一预订设备周期性向后台系统发送请求报文,以请求获取商家在指定时间段内的全量产品数据。
可选地,全量产品数据包括以下至少一项:
商家标识,是指商家在数据库中的身份标识(IDentity,ID),比如,在数据库中不同的景区通过不同的ID来标记;
产品价格,是指产品的售卖价格;
渠道标识,是指产品的售卖渠道的ID,不同的售卖渠道有不同的ID,比如,线下渠道的标识为“01”,线上渠道的标识为“02”;
产品标识,是指产品的ID,不同的产品有不同的ID,比如,景区1中包括景点1和景点2,景点1的门票的标识为“0000 0001”,景点2的门票的标识为“0000 0010”;
产品名称,是指产品的名称,比如,产品名称为“梅园景区门票”;
价格日期,是指产品以其产品价格售卖的日期,比如,景区淡季与旺季的门票价格不同;
剩余库存,是指可售卖的产品的剩余数量,比如,景区需要控制每天的客流量,因此每天的门票数量是有限的,在售卖出一定量的门票后,门票每天还可以有剩余库存;
市场价,是指市场上产品的价位;
渠道价,是指渠道上产品的价位,需要说明的是,不同的售卖渠道可能有不同的产品价格,比如,相同的产品,渠道商1定位的产品价格为45元,渠道商2定位的产品价格为43元;
结算价,是指用户购买产品时结算的价格;
产品上线信息,是指产品的上线情况,上线情况可以包括产品已上线,或产品已下线,或产品即将上线;
渠道产品标识,是指在渠道上产品的ID,比如,相同的产品,在不同的渠道上产品ID不同;
场馆标识,是指产品售卖地点的ID,比如,景区设置有南售票口与北售票口,其中,南售票口的场馆标识为“001”,北售票口的场馆标识为“002”;
场馆名称,是指产品售卖地点的的名称,比如,景区的场馆名称可以为“南售票口”,以及“北售票口”。
步骤204,统一预订设备接收后台系统发送的响应报文。
响应报文是用于响应请求报文的报文,该响应报文中包括全量产品数据;该响应报文是由后台系统基于请求报文生成包括全量产品数据的响应报文,之后反馈至统一预订设备。
步骤206,统一预订设备将全量产品数据存储至数据库中。
统一预订设备在接收到响应报文之后,从响应报文中获取全量产品数据,将上述全量产品数据存储至数据库中。
数据库中全量产品数据时按照预设格式存储的。在一些实施例中,响应报文中的全量产品数据是按照预设格式生成的,则统一预设设备将得到的全量产品数据存储至数据库中。
在一些实施例中,响应报文中的全量产品数据不是按照预设格式生成的,统一预订设备将得到的全量产品数据设置为预设格式对应存储至数据库中。
需要说明的是,若数据库中存在与响应报文中产品数据相同的历史产品数据,则对历史产品数据进行覆盖,即将全量产品数据更新至数据库中。
综上所述,本实施例提供的产品数据的存储方法,通过在售检票系统和后台系统之间设置统一预订设备,由统一预订设备通过产品接口向后台系统发送对全量产品数据的请求,从后台系统中获取商家在指定时间段内的全量产品数据,并将上述全量产品数据存储至数据库中,实现了不论系统商有多少个,也不论系统商是否发生了更换,均使用产品接口来获取全量产品数据,进而将全量产品数据沉淀在数据库中,供景区工作人员的分析和使用,提高了景区自身的数据中心的数据使用率和抗风险性。
请参考图3,示出了本申请一个示例性实施例提供的产品数据的发送方法的流程图。本实施例以该方法应用于图1所示的后台系统160中来举例说明。该方法包括:
步骤302,后台系统接收统一预订设备调用产品接口发送的请求报文。
请求报文用于获取商家在指定时间段内的全量产品数据。其中,上述指定时间段是基于用户需求设置的,比如,景区每天需要对未来90天的产品数据进行维护,则上述未来90天即为指定时间段。
可选地,上述请求报文是由统一预订设备周期性发送至后台系统,示例性的,上述周期可以是一天,比如,统一预订设备每天22点向后台系统发送请求报文,请求指定商家在指定时间段内的全量产品数据。需要说明的是,不同的商家对全量产品数据的请求周期相同或不同,指定时间段相同或不同。
步骤304,后台系统根据请求报文获取全量产品数据。
响应于后台系统接收到请求报文,后台系统获取商家在指定时间段内的全量产品数据。
步骤306,后台系统向统一预订设备发送包括全量产品数据的响应报文。
上述响应报文用于响应上述请求报文;后台系统生成包括全量产品数据的响应报文,向统一预订设备发送包括全量产品数据的响应报文。
可选地,统一预订设备上包括产品存储接口,后台系统调用产品存储接口向统一预订设备发送包括全量产品数据的响应报文。产品存储接口是统一接口中的一类,即是统一预订设备和后台系统之间的一类程序接口。上述产品存储接口是由统一预订设备向后台系统提供的程序接口;上述产品存储接口适用于统一预订设备与至少两个不同的后台系统之间的信息交互。可选地,上述产品存储接口适用于至少两个不同的后台系统向统一预订设备发送响应报文。
可选地,全量产品数据包括以下至少一项:
商家标识,产品价格,渠道标识,产品标识,产品名称,价格日期,剩余库存,市场价,渠道价,结算价,产品上线信息,渠道产品标识,场馆标识,场馆名称。
综上所述,本实施例提供的产品数据的发送方法,通过在售检票系统和后台系统之间设置统一预订设备,由统一预订设备通过产品接口向后台系统发送对全量产品数据的请求,从后台系统中获取商家在指定时间段内的全量产品数据,并将上述全量产品数据存储至数据库中,实现了不论系统商有多少个,也不论系统商是否发生了更换,均使用产品接口来获取全量产品数据,进而将全量产品数据沉淀在数据库中,供景区工作人员的分析和使用,提高了景区自身的数据中心的数据使用率和抗风险性。
请参考图4,示出了本申请的另一个示例性实施例提供的产品数据的存储方法的流程图。本实施例以该方法应用于图1所示的统一预订系统140中来举例说明。该方法包括:
步骤402,统一预订设备获取请求报文模板和至少一个请求参数。
统一预订设备中存储有请求报文模板,该请求报文模板是按照产品接口对应的格式要求设置的;至少一个请求参数包括产品价格日历请求标识,该产品价格日历请求标识用于向后台系统请求获取全量产品数据。其中,上述产品价格日历是指按照日期顺序存储的指定商家的全量产品数据的表,全量产品数据中包括产品价格。需要说明的是,由于一个产品可以在一段时间内进行售卖,不同日期下可以存储有相同的产品数据。
可选地,至少一个请求参数还包括以下至少一项:
商家标识,日历页数,每页产品项数,产品上线信息,价格开始时间,价格结束时间,渠道标识;
其中,上述日历页数是指产品价格日历的页数;上述每页产品项数是指每一页上的产品项数,比如,每一页上可以包括50条产品数据;上述价格开始时间是指产品以一个产品价格售卖的开始时间;上述价格结束时间是指产品以一个产品价格售卖的结束时间。
步骤404,统一预订设备根据请求报文模板和至少一个请求参数生成请求报文。
上述至少一个请求参数包括产品价格日历请求标识,该产品价格日历请求标识用于向后台系统请求获取全量产品数据。
统一预订设备将至少一个请求参数对应填充至请求报文模板中对应的字段,生成请求报文。示例性的,上述请求报文模板是按照产品接口对应的格式要求设置的,其中,请求报文模板的第一字段填充的是产品价格日历请求标识,第二字段填充的是商家标识。
步骤406,统一预订设备调用产品接口向后台系统发送请求报文。
可选地,统一预订设备采用POST方式调用产品接口,向统一资源定位符(UniformResource Location,URL)所指示的后台系统发送请求报文。
至少两个不同的后台系统中每一个后台系统对应设置有一个URL。示例性的,统一预订设备中存储有后台系统与URL的对应关系,比如,如表一,后台系统1对应URL 1,后台系统2对应URL 2。统一预订设备在向后台系统发送请求报文时,首先需要从上述对应关系中查询后台系统对应的URL。
表一
后台系统 URL
后台系统1 URL 1
后台系统2 URL 2
若后台系统1为商家1提供系统服务,后台系统2为商家2提供系统服务;当需要获取商家1的全量产品数据时,在上述对应关系中查找得到商家1对应的后台系统1的URL 1,之后通过URL 1路径将请求报文发送至后台系统1;当需要获取商家2的全量产品数据时,在上述对应关系中查找得到商家2对应的后台系统2的URL 2,之后通过URL 2路径将请求报文发送至后台系统2。
步骤408,后台系统接收统一预订设备调用产品接口发送的请求报文。
步骤410,后台系统根据请求报文获取全量产品数据。
响应于识别到请求报文中的产品价格日历请求标识,后台系统获取商家在指定时间段内的全量产品数据。
可选地,后台系统是基于请求报文中的请求参数来获取商家在指定时间段内的全量产品数据。示例性的,后台系统基于商家标识、日历页数、每页产品项数、产品上线信息、价格开始时间、价格结束时间、渠道标识中的至少一项请求参数来获取商家在指定时间段内的全量产品数据。比如,后台系统获取商家标识对应的指定商家在指定时间段内的全量标识;又比如,后台系统获取第i页的j项产品数据,i、j均为正整数。
步骤412,后台系统获取响应报文模板和至少两个响应参数。
后台系统中存储有响应报文模板。可选地,该响应报文模板是按照产品存储接口对应的格式要求设置的。
至少两个响应参数包括全量产品数据和产品价格日历返回标识,上述产品价格日历返回标识用于向统一预订设备返回全量产品数据。
可选地,上述至少两个响应参数还包括以下至少一项:
交互码,交互描述信息,商家标识,产品价格集合,渠道标识,产品标识,产品名称,价格日期,剩余库存,市场价,渠道价,结算价,产品上线信息,渠道产品标识,场馆标识,场馆名称;
其中,交互码是指统一预订设备与后台系统之间信息交互的凭证;交互描述信息是指统一预订设备与后台系统之间交互信息的内容描述。
步骤414,后台系统根据响应报文模板和至少两个响应参数生成响应报文。
后台系统将至少两个响应参数对应填充至响应报文模板中对应的字段,生成响应报文。示例性的,响应报文模板的第一字段填充的是产品价格日历返回标识,第二字段填充的是商家标识,第三字段填充的是产品名称,第四字段填充的是产品价格。
步骤416,后台系统向统一预订设备发送响应报文。
步骤418,统一预订设备接收后台系统发送的响应报文。
步骤420,统一预订设备将全量产品数据存储至数据库中。
响应于识别到响应报文中的产品价格日历返回标识,统一预订设备从响应报文中获取全量产品数据,将全量产品数据存储至数据库中。
综上所述,本实施例提供的产品数据的存储方法,通过在售检票系统和后台系统之间设置统一预订设备,由统一预订设备通过产品接口向后台系统发送对全量产品数据的请求,从后台系统中获取商家在指定时间段内的全量产品数据,并将上述全量产品数据存储至数据库中,实现了不论系统商有多少个,也不论系统商是否发生了更换,均使用产品接口来获取全量产品数据,进而将全量产品数据沉淀在数据库中,供景区工作人员的分析和使用,提高了景区自身的数据中心的数据使用率和抗风险性。
请参考图5,示出了本申请的另一个示例性实施例提供的产品数据的存储方法的流程图。本实施例以该方法应用于图1所示的统一预订系统140和后台系统160中来举例说明。该方法包括:
步骤501,统一预订设备获取商家ID,基于商家ID构造请求报文。
统一预订设备获取第i个商家的商家ID,按照产品接口的接口规范构造与上述商家ID对应的请求报文;该请求报文用于请求第i个商家的指定时间段内的产品数据,i为正整数。
步骤502,统一预订设备分批拉取产品数据。
统一预订设备采用POST方式将请求报文发送给后台系统,请求从后台系统中分批拉取产品数据。示例性的,统一预订设备请求按照产品价格日历的日历页数从后台系统中分批次拉取产品数据,每一页可以包括50条产品数据,即请求每一批拉取50条产品数据。
示例性的,统一预订设备请求拉取第i个商家在未来3个月内的售卖产品中第j批产品数据,第j批产品数据即为未来3个月内售卖产品的价格日历中第j页产品数据,j为正整数。
步骤503,后台系统处理请求报文,基于请求报文构造响应报文。
示例性的,后台系统接收到请求报文后,处理请求报文,基于商家ID分批次获取第i个商家的产品价格日历中第j页产品数据,基于产品数据构造响应报文,其中,每一个响应报文中包括一个批次的产品数据。
步骤504,后台系统分批返回商家的产品数据。
示例性的,后台系统向统一预订设备返回第j批产品数据的响应报文,即该响应报文中包括上述第j批产品数据。
步骤505,统一预订设备将产品数据存储至数据库;获取下一批产品数据,直至该商家的产品数据获取完成,获取下一个商家ID,分批拉取该商家ID对应的产品数据。
统一预订设备接收到响应报文后,从响应报文中获取第i个商家的第j批产品数据,将第j批产品数据存储至数据库中,继续获取第i个商家的下一批产品数据,即第j+1批产品数据,直至第i个商家在指定时间段内的产品数据获取完成。之后,获取第i+1个商家的商家ID,重复步骤501至步骤505,直至L个商家在指定时间段内的产品数据均获取完成,其中,L个商家均为需要拉取产品数据的商家,L为正整数。
上述指定时间段是预先设置的,示例性的,上述指定时间段的时长可以是一周、一个月、三个月、一年等,本申请中对指定时间段的时长不加以限定。
综上所述,本实施例提供的产品数据的存储方法,通过在售检票系统和后台系统之间设置统一预订设备,由统一预订设备通过产品接口向后台系统发送对全量产品数据的请求,从后台系统中获取商家在指定时间段内的全量产品数据,并将上述全量产品数据存储至数据库中,实现了不论系统商有多少个,也不论系统商是否发生了更换,均使用产品接口来获取全量产品数据,进而将全量产品数据沉淀在数据库中,供景区工作人员的分析和使用,提高了景区自身的数据中心的数据使用率和抗风险性。
5.1下面对产品接口进行示例性说明:
5.1.1使用场景:
1、我方主动调用合作方此接口,分页获取指定商家全量产品的价格、库存等信息。
2、定时调用,每日22点开始。
3、每页默认拉取50条数据,可依照系统商实际能力进行数据调整。
5.1.2请求方法:POST
5.1.3请求地址:合作方提供
5.1.4请求参数:
Figure BDA0002395672770000151
5.1.5响应结果:
Figure BDA0002395672770000161
5.1.6 Code说明:
错误码 错误描述 解决方案
200 返回成功
101 参数错误 检查参数的合法性
102 系统异常 调用方重试
199 其他 根据describe中信息处理,或者联系运营人员
5.1.7示例:1、请求参数示例:
Figure BDA0002395672770000171
2、响应结果示例:
Figure BDA0002395672770000172
Figure BDA0002395672770000181
请参考图6,示出了本申请一个示例性实施例提供的产品数据的存储装置的框图。该装置是位于售检票系统和后台系统之间的装置,该装置可以通过软件、硬件、或者二者结合实现成为服务器的部分或者全部,该装置包括:第一发送模块520、第一接收模块540和存储模块560。
第一发送模块520,用于通过产品接口向后台系统发送请求报文,请求报文用于获取商家在指定时间段内的全量产品数据,产品接口适用于统一预订设备与至少两个不同的后台系统之间的信息交互,产品接口是后台系统提供的接口;
第一接收模块540,用于接收后台系统发送的响应报文,响应报文中包括全量产品数据;
存储模块560,用于将全量产品数据存储至数据库中。
在一个示例性的例子中,第一发送模块520,包括:
第一获取子模块522,用于获取请求报文模板和至少一个请求参数,至少一个请求参数包括产品价格日历请求标识,产品价格日历请求标识用于向后台系统请求获取全量产品数据;
第一生成子模块524,用于根据请求报文模板和至少一个请求参数生成请求报文;
第一发送子模块526,用于调用产品接口向后台系统发送请求报文。
在一个示例性的例子中,第一发送模块520,用于采用POST方式调用产品接口,向统一资源定位符所指示的后台系统发送请求报文。
在一个示例性的例子中,至少一个请求参数还包括以下至少一项:
商家标识,日历页数,每页产品项数,产品上线信息,价格开始时间,价格结束时间,渠道标识。
在一个示例性的例子中,全量产品数据包括以下至少一项:
商家标识,产品价格,渠道标识,产品标识,产品名称,价格日期,剩余库存,市场价,渠道价,结算价,产品上线信息,渠道产品标识,场馆标识,场馆名称。
综上所述,本实施例提供的产品数据的存储装置,通过在售检票系统和后台系统之间设置统一预订设备,由统一预订设备通过产品接口向后台系统发送对全量产品数据的请求,从后台系统中获取商家在指定时间段内的全量产品数据,并将上述全量产品数据存储至数据库中,实现了不论系统商有多少个,也不论系统商是否发生了更换,均使用产品接口来获取全量产品数据,进而将全量产品数据沉淀在数据库中,供景区工作人员的分析和使用,提高了景区自身的数据中心的数据使用率和抗风险性。
请参考图7,示出了本申请一个示例性实施例提供的产品数据的发送装置的框图。上述产品数据的发送装置应用于后台系统中,该装置可以通过软件、硬件、或者二者结合实现成为服务器的部分或者全部,该装置包括:第二接收模块620,获取模块640和第二发送模块660。
第二接收模块620,用于接收统一预订设备调用产品接口发送的请求报文,请求报文用于获取商家在指定时间段内的全量产品数据,产品接口适用于统一预订设备与至少两个不同的后台系统之间的信息交互,统一预订设备是位于售检票系统和后台系统之间的设备;
获取模块640,用于根据请求报文获取全量产品数据;
第二发送模块660,用于向统一预订设备发送包括全量产品数据的响应报文。
在一个示例性的例子中,第二发送模块660,包括:
第二获取子模块662,用于获取响应报文模板和至少两个响应参数,至少两个响应参数包括全量产品数据和产品价格日历返回标识,产品价格日历返回标识用于向统一预订设备返回全量产品数据;
第二生成子模块664,用于根据响应报文模板和至少两个响应参数生成响应报文;
第二发送子模块666,用于向统一预订设备发送响应报文。
在一个示例性的例子中,至少两个响应参数还包括以下至少一项:
交互码,交互描述信息,商家标识,产品价格集合,渠道标识,产品标识,产品名称,价格日期,剩余库存,市场价,渠道价,结算价,产品上线信息,渠道产品标识,场馆标识,场馆名称。
在一个示例性的例子中,请求报文是由统一预订设备采用POST方式调用产品接口,向统一资源定位符所指示的后台系统发送的请求报文。
综上所述,本实施例提供的产品数据的发送装置,通过在售检票系统和后台系统之间设置统一预订设备,由统一预订设备通过产品接口向后台系统发送对全量产品数据的请求,从后台系统中获取商家在指定时间段内的全量产品数据,并将上述全量产品数据存储至数据库中,实现了不论系统商有多少个,也不论系统商是否发生了更换,均使用产品接口来获取全量产品数据,进而将全量产品数据沉淀在数据库中,供景区工作人员的分析和使用,提高了景区自身的数据中心的数据使用率和抗风险性。
请参考图8,示出了本申请一个示例性实施例提供的计算机设备的结构示意图。该计算机设备可以是上述系统中的统一预订设备。具体来讲:
计算机设备700包括中央处理单元(CPU,Central Processing Unit)701、包括随机存取存储器(RAM,Random Access Memory)702和只读存储器(ROM,Read Only Memory)703的系统存储器704,以及连接系统存储器704和中央处理单元701的系统总线705。计算机设备700还包括帮助计算机内的各个器件之间传输信息的基本输入/输出系统(I/O系统,Input Output System)706,和用于存储操作系统713、应用程序714和其他程序模块715的大容量存储设备707。
基本输入/输出系统706包括有用于显示信息的显示器708和用于用户输入信息的诸如鼠标、键盘之类的输入设备709。其中显示器708和输入设备709都通过连接到系统总线705的输入输出控制器710连接到中央处理单元701。基本输入/输出系统706还可以包括输入输出控制器710以用于接收和处理来自键盘、鼠标、或电子触控笔等多个其他设备的输入。类似地,输入输出控制器710还提供输出到显示屏、打印机或其他类型的输出设备。
大容量存储设备707通过连接到系统总线705的大容量存储控制器(未示出)连接到中央处理单元701。大容量存储设备707及其相关联的计算机可读介质为计算机设备700提供非易失性存储。也就是说,大容量存储设备707可以包括诸如硬盘或者紧凑型光盘只读存储器(CD-ROM,Compact Disc Read Only Memory)驱动器之类的计算机可读介质(未示出)。
计算机可读介质可以包括计算机存储介质和通信介质。计算机存储介质包括以用于存储诸如计算机可读指令、数据结构、程序模块或其他数据等信息的任何方法或技术实现的易失性和非易失性、可移动和不可移动介质。计算机存储介质包括RAM、ROM、可擦除可编程只读存储器(EPROM,Erasable Programmable Read Only Memory)、带电可擦可编程只读存储器(EEPROM,Electrically Erasable Programmable Read Only Memory)、闪存或其他固态存储其技术,CD-ROM、数字通用光盘(DVD,Digital Versatile Disc)或固态硬盘(SSD,Solid State Drives)、其他光学存储、磁带盒、磁带、磁盘存储或其他磁性存储设备。其中,随机存取记忆体可以包括电阻式随机存取记忆体(ReRAM,Resistance RandomAccess Memory)和动态随机存取存储器(DRAM,Dynamic Random Access Memory)。当然,本领域技术人员可知计算机存储介质不局限于上述几种。上述的系统存储器704和大容量存储设备707可以统称为存储器。
根据本申请的各种实施例,计算机设备700还可以通过诸如因特网等网络连接到网络上的远程计算机运行。也即计算机设备700可以通过连接在系统总线705上的网络接口单元711连接到网络712,或者说,也可以使用网络接口单元711来连接到其他类型的网络或远程计算机系统(未示出)。
上述存储器还包括一个或者一个以上的程序,一个或者一个以上程序存储于存储器中,被配置由CPU执行。
在一个可选的实施例中,提供了一种计算机设备,该计算机设备包括处理器和存储器,存储器中存储有至少一条指令、至少一段程序、代码集或指令集,至少一条指令、至少一段程序、代码集或指令集由处理器加载并执行以实现如上所述的产品数据的存储方法,或者,产品数据的发送方法。
在一个可选的实施例中,提供了一种计算机可读存储介质,该存储介质中存储有至少一条指令、至少一段程序、代码集或指令集,至少一条指令、至少一段程序、代码集或指令集由处理器加载并执行以实现如上所述的产品数据的存储方法,或者,产品数据的发送方法。
可选地,该计算机可读存储介质可以包括:只读存储器(ROM,Read Only Memory)、随机存取记忆体(RAM,Random Access Memory)、固态硬盘(SSD,Solid State Drives)或光盘等。其中,随机存取记忆体可以包括电阻式随机存取记忆体(ReRAM,Resistance RandomAccess Memory)和动态随机存取存储器(DRAM,Dynamic Random Access Memory)。上述本申请实施例序号仅仅为了描述,不代表实施例的优劣。
本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成,也可以通过程序来指令相关的硬件完成,所述的程序可以存储于一种计算机可读存储介质中,上述提到的存储介质可以是只读存储器,磁盘或光盘等。
请参考图9,示出了本申请一个示例性实施例提供计算机系统800,该计算机系统800包括售检票系统820、产品数据的存储系统840、以及后台系统860;其中,统一预订设备840是位于售检票系统820和后台系统860之间的设备。
产品数据的存储系统840包括:统一预订设备842和数据库844;
统一预订设备842,用于执行如上述示例性实施例提供的产品数据的存储方法,以将全量产品数据存储至数据库844中;
数据库844,用于存储全量产品数据。
本申请还提供一种计算机可读存储介质,该存储介质中存储有至少一条指令、至少一段程序、代码集或指令集,该至少一条指令、至少一段程序、代码集或指令集由处理器加载并执行以实现上述各方法实施例提供的产品数据的存储方法,或者,产品数据的发送方法。
应当理解的是,在本文中提及的“多个”是指两个或两个以上。“和/或”,描述关联对象的关联关系,表示可以存在三种关系,例如,A和/或B,可以表示:单独存在A,同时存在A和B,单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。
本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成,也可以通过程序来指令相关的硬件完成,所述的程序可以存储于一种计算机可读存储介质中,上述提到的存储介质可以是只读存储器,磁盘或光盘等。
以上所述仅为本申请的可选实施例,并不用以限制本申请,凡在本申请的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本申请的保护范围之内。

Claims (14)

1.一种产品数据的存储方法,其特征在于,应用于统一预订设备中,所述统一预订设备是位于售检票系统和后台系统之间的设备,所述方法包括:
通过产品接口向所述后台系统发送请求报文,所述请求报文用于获取商家在指定时间段内的全量产品数据,所述产品接口适用于所述统一预订设备与至少两个不同的后台系统之间的信息交互,所述产品接口是所述后台系统提供的接口;
接收所述后台系统发送的响应报文,所述响应报文中包括所述全量产品数据;
将所述全量产品数据存储至数据库中。
2.根据权利要求1所述的方法,其特征在于,所述通过产品接口向所述后台系统发送请求报文,包括:
获取请求报文模板和至少一个请求参数,所述至少一个请求参数包括产品价格日历请求标识,所述产品价格日历请求标识用于向所述后台系统请求获取所述全量产品数据;
根据所述请求报文模板和所述至少一个请求参数生成所述请求报文;
调用所述产品接口向所述后台系统发送所述请求报文。
3.根据权利要求2所述的方法,其特征在于,所述调用所述产品接口向所述后台系统发送所述请求报文,包括:
采用POST方式调用所述产品接口,向统一资源定位符所指示的所述后台系统发送所述请求报文。
4.根据权利要求2或3所述的方法,其特征在于,所述至少一个请求参数还包括以下至少一项:
商家标识,日历页数,每页产品项数,产品上线信息,价格开始时间,价格结束时间,渠道标识。
5.根据权利要求1至3任一所述的方法,其特征在于,所述全量产品数据包括以下至少一项:
商家标识,产品价格,渠道标识,产品标识,产品名称,价格日期,剩余库存,市场价,渠道价,结算价,产品上线信息,渠道产品标识,场馆标识,场馆名称。
6.一种产品数据的发送方法,其特征在于,应用于后台系统中,所述后台系统上包括产品接口,所述方法包括:
接收统一预订设备调用所述产品接口发送的请求报文,所述请求报文用于获取商家在指定时间段内的全量产品数据,所述产品接口适用于所述统一预订设备与至少两个不同的后台系统之间的信息交互,所述统一预订设备是位于售检票系统和所述后台系统之间的设备;
根据所述请求报文获取所述全量产品数据;
向所述统一预订设备发送包括所述全量产品数据的响应报文。
7.根据权利要求6所述的方法,其特征在于,所述向所述统一预订设备发送包括所述全量产品数据的响应报文,包括:
获取响应报文模板和至少两个响应参数,所述至少两个响应参数包括所述全量产品数据和产品价格日历返回标识,所述产品价格日历返回标识用于向所述统一预订设备返回所述全量产品数据;
根据所述响应报文模板和所述至少两个响应参数生成所述响应报文;
向所述统一预订设备发送所述响应报文。
8.根据权利要求7所述的方法,其特征在于,所述至少两个响应参数还包括以下至少一项:
交互码,交互描述信息,商家标识,产品价格集合,渠道标识,产品标识,产品名称,价格日期,剩余库存,市场价,渠道价,结算价,产品上线信息,渠道产品标识,场馆标识,场馆名称。
9.根据权利要求6至8任一所述的方法,其特征在于,所述请求报文是由所述统一预订设备采用POST方式调用所述产品接口,向统一资源定位符所指示的所述后台系统发送的所述请求报文。
10.一种产品数据的存储装置,其特征在于,所述装置是位于售检票系统和后台系统之间的装置,所述装置包括:
第一发送模块,用于通过产品接口向所述后台系统发送请求报文,所述请求报文用于获取商家在指定时间段内的全量产品数据,所述产品接口适用于所述统一预订设备与至少两个不同的后台系统之间的信息交互,所述产品接口是所述后台系统提供的接口;
第一接收模块,用于接收所述后台系统发送的响应报文,所述响应报文中包括所述全量产品数据;
存储模块,用于将所述全量产品数据存储至数据库中。
11.一种产品数据的发送装置,其特征在于,应用于后台系统中,所述后台系统上包括产品接口,所述装置包括:
第二接收模块,用于接收统一预订设备调用所述产品接口发送的请求报文,所述请求报文用于获取商家在指定时间段内的全量产品数据,所述产品接口适用于所述统一预订设备与至少两个不同的后台系统之间的信息交互,所述统一预订设备是位于售检票系统和所述后台系统之间的设备;
获取模块,用于根据所述请求报文获取所述全量产品数据;
第二发送模块,用于向所述统一预订设备发送包括所述全量产品数据的响应报文。
12.一种产品数据的存储系统,其特征在于,所述系统包括:统一预订设备和数据库,所述统一预订设备是位于售检票系统和后台系统之间的设备;
所述统一预订设备,用于执行如权利要求1至5任一所述的产品数据的存储方法,以将全量产品数据存储至所述数据库中;
所述数据库,用于存储所述全量产品数据。
13.一种计算机设备,其特征在于,所述计算机设备包括:处理器和存储器,所述存储器存储有计算机程序,所述计算机程序由所述处理器加载并执行以实现如权利要求1至5任一所述的产品数据的存储方法,或者,如权利要求6至9任一所述的产品数据的发送方法。
14.一种计算机可读存储介质,其特征在于,所述计算机可读存储介质中存储有计算机程序,所述计算机程序由处理器加载并执行以实现如权利要求1至5任一所述的产品数据的存储方法,或者,如权利要求6至9任一所述的产品数据的发送方法。
CN202010130581.6A 2020-02-28 2020-02-28 产品数据的存储方法、发送方法、装置及存储介质 Withdrawn CN111324780A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010130581.6A CN111324780A (zh) 2020-02-28 2020-02-28 产品数据的存储方法、发送方法、装置及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010130581.6A CN111324780A (zh) 2020-02-28 2020-02-28 产品数据的存储方法、发送方法、装置及存储介质

Publications (1)

Publication Number Publication Date
CN111324780A true CN111324780A (zh) 2020-06-23

Family

ID=71173088

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010130581.6A Withdrawn CN111324780A (zh) 2020-02-28 2020-02-28 产品数据的存储方法、发送方法、装置及存储介质

Country Status (1)

Country Link
CN (1) CN111324780A (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111950248A (zh) * 2020-08-10 2020-11-17 中国工商银行股份有限公司 基于xml的产品报告生成方法及系统

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020042756A1 (en) * 2000-10-05 2002-04-11 I2 Technologies, Us, Inc. Fulfillment management system for managing ATP data in a distributed supply chain environment
CN101877158A (zh) * 2010-03-23 2010-11-03 苏州德融嘉信信用管理技术有限公司 一种银行前置业务平台及其运行处理方法
CN108805473A (zh) * 2017-04-26 2018-11-13 上海橙亚商务咨询有限公司 利用先进的价格/履行日期匹配程序来优化产品定价和库存管理的系统和方法
CN109885779A (zh) * 2019-01-09 2019-06-14 中国平安人寿保险股份有限公司 子系统管理方法、装置、计算机装置及存储介质
CN109947994A (zh) * 2018-08-10 2019-06-28 北京京东金融科技控股有限公司 支付过程的处理方法、装置、介质及电子设备
CN110300190A (zh) * 2019-07-25 2019-10-01 中国工商银行股份有限公司 一种基于mqtt消息中间件的售检票系统
CN110619555A (zh) * 2019-08-15 2019-12-27 中国平安财产保险股份有限公司 订单信息的统一管理方法、装置、终端设备及介质

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020042756A1 (en) * 2000-10-05 2002-04-11 I2 Technologies, Us, Inc. Fulfillment management system for managing ATP data in a distributed supply chain environment
CN101877158A (zh) * 2010-03-23 2010-11-03 苏州德融嘉信信用管理技术有限公司 一种银行前置业务平台及其运行处理方法
CN108805473A (zh) * 2017-04-26 2018-11-13 上海橙亚商务咨询有限公司 利用先进的价格/履行日期匹配程序来优化产品定价和库存管理的系统和方法
CN109947994A (zh) * 2018-08-10 2019-06-28 北京京东金融科技控股有限公司 支付过程的处理方法、装置、介质及电子设备
CN109885779A (zh) * 2019-01-09 2019-06-14 中国平安人寿保险股份有限公司 子系统管理方法、装置、计算机装置及存储介质
CN110300190A (zh) * 2019-07-25 2019-10-01 中国工商银行股份有限公司 一种基于mqtt消息中间件的售检票系统
CN110619555A (zh) * 2019-08-15 2019-12-27 中国平安财产保险股份有限公司 订单信息的统一管理方法、装置、终端设备及介质

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111950248A (zh) * 2020-08-10 2020-11-17 中国工商银行股份有限公司 基于xml的产品报告生成方法及系统
CN111950248B (zh) * 2020-08-10 2023-10-10 中国工商银行股份有限公司 基于xml的产品报告生成方法及系统

Similar Documents

Publication Publication Date Title
US10417657B2 (en) Point management apparatus, system, and method
US7937329B1 (en) Method and system for remotely managing business and employee administration functions
CN102253954A (zh) 画面定制支援系统和画面定制支援方法
CN106878043B (zh) 一种业务处理方法和装置
US20130318135A1 (en) Data record dynamic active content systems and methods
WO2014062282A1 (en) Transaction-driven social network
CN112308552A (zh) 医保药品的下单方法和装置
NO324359B1 (no) Fremgangsmate for tilbud, bestilling og salg av varer og tjenester
CN110796458A (zh) 信息管理系统
CN111324780A (zh) 产品数据的存储方法、发送方法、装置及存储介质
US20070198466A1 (en) By owner MLS business method
CN109597927B (zh) 招投标相关网页页面信息提取方法及系统
JP7003318B2 (ja) 情報管理装置及び情報管理方法
CN108537577A (zh) 数据的有效性查询方法及装置、存储介质、服务器
CN114445128A (zh) 卡券管理方法、装置、电子设备和计算机可读介质
CN111199427B (zh) 网络用户的分组管理方法、装置、电子设备及存储介质
RU2372656C2 (ru) Система и способ формирования и распространения информации о товарах
GB2521345A (en) Method and system for generating a quote
CN111324612A (zh) 订单信息的存储方法、系统、装置、设备及存储介质
KR101132238B1 (ko) 통합 서비스 관리 시스템 및 통합 서비스 관리 방법
JPWO2005094186A1 (ja) 電子メール自動処理プログラム、電子メール自動処理プログラムを記録した記録媒体、電子メール自動処理システム
CN110705734B (zh) 在线住宿产品的预订服务系统、方法及设备
US20160098786A1 (en) Real estate transaction system
US20200380545A1 (en) Presenting products to users based on personalized product pricing determined from user characteristics
JP2004145667A (ja) ショッピングサイトへの個人情報の伝達システム及び方法、並びにショッピングサイトにおける個人情報の更新システム及び方法

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
WW01 Invention patent application withdrawn after publication

Application publication date: 20200623

WW01 Invention patent application withdrawn after publication