企业应用_企业应用架构� - CSDN
精华内容
参与话题
  • 企业应用系统大全

    2020-05-15 15:07:13
    在企业规划信息系统中,需要了解到企业应用的名录。该文档描述了企业信息化常用的软件信息名录。
  • 什么是企业应用

    2019-08-22 18:17:00
    看到“企业应用“这次术语, 在你的下意识里,第一反应能想起哪些相关的词?我的条件反射是: ERP, CRM, HRM, BI, CMS ......企业应用这个词听起来...
        

    看到“企业应用“这次术语, 在你的下意识里,第一反应能想起哪些相关的词?

    我的条件反射是: ERP,  CRM, HRM, BI, CMS ......

    企业应用这个词听起来很高大上,  但是什么“企业应用”?  我发现我没法下一个准确的定义。

    回顾下我的工作经历, 应聘的时候似乎都是要做"企业应用" 开发。

    毕业后第一份工作就是做很热门的OA系统,就是所谓的办公自动化,包括了邮件、工作流、表单、文档系统等公司信息化需求, 用户肯定是部署OA的企业内部人士,算是最基本的企业应用开发吧。

    后来做了欧洲的税务系统,实现他们各种各种复杂的业务逻辑,用户也是税务局的员工, 应该是标准的企业应用。

    再后来做一个庞大的系统来支持公司的产品销售,用户既有公司的销售人员,也有外部的用户。 系统相当复杂, 由很多子系统组成,各个子系统还存在着复杂的关系, 接口五花八门,有的用Webservice , 有的用数据复制, 有的用MQ, 甚至还有邮件接口和FTP接口,  这应该也是一个典型的企业应用。

    似乎一个企业应用就是帮助企业干活的信息系统,满足企业日常运营,  帮助他们完成流程的信息化。

    人称软件教父的Martin Flower 非常善于抽象,   在著名的《企业应用架构模式》一书中他就针对企业应用抽象出这么几点:

    1. 企业应用一般涉及到持久化数据

    初一看似乎是废话: 如果数据不能持久化,应用也没什么意思了。

    实际上重点是企业数据的生存年限相当的长, 甚至比访问这些数据的程序都要长,无论硬件、操作系统、应用程序怎么变,数据都不能受到损害。

    2. 企业应用一般涉及大量数据

    这是毫无疑问的, 一个企业运行过程中绝对不仅仅产生几千,几万条数据。

    3. 企业应用涉及到很多人同时访问数据

    如果是内部系统还好, 要是对外的Web系统, 那用户量可能非常大。

    4. 企业应用涉及到大量的用户操作界面

    有几百个界面毫不为奇, 用户使用频率差异很大,特别是这些用户没有技术背景。

    5. 企业应用很少独立存在, 通常需要与散布在企业周围的其他应用进行集成。

    这些各种各样的系统是在不同时期, 用不同的技术构建起来的, 把他们集成起来的痛苦经历过的码农才知道。

    但是互联网应用像淘宝,京东商城是否属于企业应用的范畴?    Martin Flower并没有明确说明。互联网应用符合了上面的第2,3两点,  数据量巨大, 高并发访问, 技术上要求规模大、扩展性强、可靠性高 。

    既然难于区分,  我想不妨根据用户的不同, 分为两个大类:


    1. 面向企业用户

    ERP(企业资源规划),  CRM(客户关系管理) , HRM(人力资源管理),SCM(供应链管理), BI(商业智能) ,还有各种各样根据企业的需求做的定制软件(例如营销系统) 等应该属于这一类。

    这类应用的用户数不会像互联网应用那样特别巨大, 但是业务逻辑一般比较复杂, 为了实现这些变态的,多变的逻辑经常得付出巨大的代价。

    稍微大点的企业都会涉及到应用之间的集成问题, 这又是一个大坑。

    由于用户主要是企业内部人员, 直接用于企业的生产环境,  一旦出错, 整个公司的活动都可能受影响, 所以对可靠性, 稳定性要求较高。

    这类应用一般都是收费的,并且价格不菲。 既然是掏了真金白银, 系统出了故障,客户一般会怒气冲冲的跳起来找售后。

    2. 面向消费者用户

    电子商务、社交、娱乐、通信等互联网应用属于这一类,相比而言, 消费者对于出错的容忍度要高一点 :  你肯定不会因为微信发不了朋友圈而去找腾讯要赔偿, 最多骂几句而已。

    由于这类应用的用户量巨大, 高并发访问的特质, 即使是简单的业务逻辑,实现起来也很不容易, 例如从数据库读取信息然后展示, 如果是几十个人或者上百人访问,可能直接发出SQL查询数据库就搞定了;  如果有几万甚至几十万访问, 那非得搞一些缓存,分布式,页面静态化等技术来搞定了。  


    由于用户是直接的消费者, 产品的体验至关重要,用起来不爽, 用户马上用脚投票,分分钟抛弃你。


    当然这些互联网应用肯定有后台的管理系统,用来做运营、营销和数据分析, 这又属于第一类的范畴了。

    码农翻身相关历史文章推荐:


    Java EE

    我是一个线程

    我是一个Java class

    Java:一个帝国的诞生

    JDBC诞生记

    JDBC后传

    一个不安分的JDBC驱动

    JSP:一个装配工的没落

    Javascript: 一个屌丝的逆袭

    Spring本质系列(1) -- 依赖注入

    Spring本质系列(2) -- AOP

    Http 历险记(上)

    Http 历险记(下)—Struts的秘密

    三层架构和MVC那点事儿

    Java帝国之 Java Bean(上)

    Java帝国之 Java Bean(下)

    计算机网络

    我是一个路由器

    我是一个网卡

    TCP/IP之大明邮差

    TCP/IP之大明内阁

    TCP/IP之蓟辽督师

    张大胖的socket

    IE为什么把Chrome和火狐打伤了?

    对浏览器村的第二次采访

    节约标兵IE的自述

    EMail诞生记

    EMail诞生记(下)

    操作系统

    我是一个进程

    CPU阿甘

    CPU阿甘之烦恼  

    我是一个键盘

    我是一块硬盘(上)  

    我是一块硬盘(下)

    那些烦人的同步和互斥问题  

    冯·诺伊曼计算机的诞生

    数据库

    小李的数据库之旅(上)

    小李的数据库之旅(下)

    张大胖学数据库

    数据库村的旺财和小王

    你看到的只是冰山一角, 更多精彩文章,尽在“码农翻身” 微信公众号, 回复消息"m"或"目录" 查看更多文章

    有心得想和大家分享? 欢迎投稿 ! 我的联系方式:微信:liuxinlehan  QQ: 3340792577

    0?wx_fmt=jpeg

    公众号:码农翻身

    “码农翻身”公众号由工作15年的前IBM架构师创建,分享编程和职场的经验教训。

    展开全文
  • 几种企业应用集成方式的比较

    千次阅读 2017-12-29 10:36:03
    尤其是很多企业应用的系统,因为我们定义的很多子系统是为了解决某个特定的问题或者问题域,在后续随着业务的发展和变化对于系统也会有更多的集成要求。于是,集成主要有哪几种方式?他们各有什么特点呢?这些问题就...

    前言

         我们做过的大部分系统其实并不是自己从头开始设计和实现的,很多时候是基于现有的基础再做扩展或者和现有的系统集成。尤其是很多企业应用的系统,因为我们定义的很多子系统是为了解决某个特定的问题或者问题域,在后续随着业务的发展和变化对于系统也会有更多的集成要求。于是,集成主要有哪几种方式?他们各有什么特点呢?这些问题就一一的浮现出来。这里主要针对一些原来个人项目中接触过的问题,结合一些前人的经验做一个总结。

    企业集成要点

        通常来说,我们需要将多个应用系统集成起来是的他们之间能够相互交互。出于系统演化和需求变更的影响,由于系统的差异导致我们集成的时候面临的困难也比较繁杂。很多时候我们最开始在设计某些系统的时候根本就没有考虑到集成的需要。因此在集成的时候主要会考虑一下几个要点:

    • 应用耦合度:这一点也和软件工程中的基本设计思想是契合的。即我们要求系统之间的依赖达到最小化,这样当一个系统发生变化的时候也会对另外一个系统产生尽可能小的影响。也就是我们所说的松耦合。
    • 侵入性:当进行集成的时候,希望集成的系统和集成功能的代码都尽可能的变动小。
    • 技术选择:不同的集成方案需要不同的软硬件,这些牵涉到开发和学习的成本。
    • 数据格式:既然系统要集成,从本质上来说就相当于两个系统的通信。那么相互通信的系统就要确定交换的数据信息格式来保证通信的正常进行。我们接触过的SOAP, REST web service, CORBA等都有特定的消息定义标准。
    • 数据时间线:集成还有一个需要考虑的就是当一个系统将需要传递数据发送给另外一个系统的时候,他们传送时间要尽可能少。这样可以提升系统整体运行的效率,减少延迟。
    • 数据或功能共享:有的应用集成还考虑到功能的集成共享。这种功能的共享带来的好处是使得一个系统提供的功能在另外一个系统看来就好像是调用本地的功能一样。一些典型的应用集成比如说RPC(远程方法调用)就符合这种特征。
    • 远程通信:通常我们系统调用是采用同步的方式。可以在一些远程通信的情况下,采用异步的方式也有它的优点,比如说带来系统效率的提升。同时也使得系统设计的复杂度变大。
    • 可靠性:我们不仅仅是设计系统集成方案,就是在一些简单系统应用里面也会考虑到,如果某个部分出错了或者失效了该怎么办?有什么办法可以提高可靠性?

        OK,有了前面这些要点,我们再结合目前几种主要的集成方式来一一讨论吧。    

    文件传输(共享)

         文件共享传输的方式是一种我们能想到的很简单直观的办法。它的典型交互场景如下:

     

         在这种场景下,我们一个应用产生包含需要提供信息的文件,然后再由另外一个应用来通过访问文件获取信息。在这里,集成部分所做的事情主要是将文件根据应用的不同需要做格式的转换。考虑这种集成方式,我们有几个重要的问题需要考虑:

    • 文件的格式:考虑到不同应用系统传递消息的具体样式不一致,A应用产生的文件如果能够给B应用直接使用是最好的了。尤其是如果如果有B应用的原生支持,对于集成来说将大大提高效率。因此,我们一些常见的方法是传递XML或者JSON格式的文本。 当然,在一些UNIX系统里面也有通过纯TXT文本传递信息的。
    • 另外一个比较重要的问题就是什么时候产生文件,什么时候处理文件。因为我们一般都需要一定的时间来产生文件,我们不太希望文件产生的太频繁。而且,在一个应用产生文件的时候怎么保证另外一个应用这个时候不去修改它呢?如果文件产生完了怎么通知另外一个应用呢?还有就是,我怎么知道另外一个应用已经处理过我处理的文件了?我们产生的文件会不会有重名的冲突?文件被处理完之后该怎么办?删除它还是重复再应用?这些问题是在消息传输比较频繁时很容易发生的。这些问题的发生会导致两个应用系统之间信息的不同步或者信息的错误,这也是采用纯文件传输的弊端。
    • 当然,在一些应用场景之下,文件传输还是有其优点的。在一些信息交换不是很频繁,而且对于信息的及时性要求不太高的情况下,这种方式还是值得考虑的。我们可以采用一些timer job的方式来产生和消费文件。只要保证两者不产生冲突和他们正确的执行顺序。集成的效果还是可以达到的。另外,采用文件传输还有一个优点就是对于集成的系统来说它比较完美的屏蔽了集成的细节。每个系统只要关注符合标准格式的文件内容,具体实现和数据交换他们都不需要关心。 

    共享数据库

         还有一种集成方式也比较常见,就是共享数据库。在很多应用开发的场景下,我们的数据库是相对独立提供服务的一部分。所以对于其他系统的对接也就比较容易,这种集成的方式如下图:

        和前面文件共享传输的方案比起来,这种方案有一个相对的优势,就是可以保证数据的一致性。在原来的方案中,如果文件要传输给多个应用的话,我们是没办法保证所有应用的数据是同步而且一致的。有可能有的快有的慢。而在这里,所有的数据都是统一存储在公共的数据库里,也就不存在这样的问题了。对于任何一个系统产生的数据或者变化,另外一个系统也就马上可以看到。

         当然,这种方案也有它不足的地方。首先一个问题就是对于多个应用来说,这个共享数据库需要能够适应他们所有的场景。不同的应用考量的点是不一样的,要能适应所有的需求对于数据库这一部分就显得尤其的困难。还有一个就是性能方面的问题,不同的应用可能会同时访问相同的数据导致数据访问冲突,因此也会带来如死锁等问题。

         所以说,这种方案出现问题的根源在于用一种统一的数据模型来解决各种不同的应用需求是并不现实的。

     

    RPC(远程过程调用)

         远程过程调用的方法在早些年的时候也比较常见。典型的如Java的RMI。典型的应用场景如下:

         以典型的java RMI为例,当我们需要访问远程方法的时候,需要定义访问的接口,然后通过相关工具生成skeleton和stub。然后一端通过stub给另外一端发送消息。在应用A本地的代码中访问stub看起来还是和调用本地方法一样,这些细节都由stub给屏蔽了。其他的技术如COM, CORBA, .net Remoting都采用了RPC的思路。

        RPC的这种思路能够很好的集成应用开发。当然,由于这种机制也会带来一定的问题,比如说java RMI或者.net remoting。他们都局限于一个平台,好比说我应用A是用java做的,那么如果要和另外一个系统通过RMI集成的话,那个系统也必须是java做的。另外,他们其实还是一种紧耦合。我们RPC调用是用的一种类似于系统api的同步调用,当一端发出调用请求的时候会在那里等待返回的结果。如果另外一个系统出现故障也会对调用方产生很大影响。而且我们用RPC调用的时候默认期望消息是按照发送的顺序给接收方的。但是由于各种环境的影响会使得接收的结果乱序,这样也可能会导致系统执行出现问题。所以从可靠性来说还是存在着一定的不足。

    消息队列

         看来前面几种集成的方式,我们再来看看消息队列的方式。消息队列的集成方式如下图:

         所有应用之间要通信的消息都通过消息队列来传输,由消息队列来保证数据传输的异步性、稳定性等。总的来说,这看起来有点像网络连接结构。所有数据通过一条可靠的链路来进行通信。

        那么,这种集成方式有哪些特征呢?

    •     更好的应用解耦:像以往采用文件传输或者共享数据库的方式需要知道文件或者数据库在哪里。对于RPC的方式来说甚至要知道对方的IP地址才能进行方法调用。这样的依赖太强烈。而且还对开发运行平台也有依赖。而现在这种方式则是只要双方规定好通信的消息格式,各自都只要发消息给消息队列就可以了。这就好比是两个人写信,一个人只要把要写的内容整理好再交给邮局,剩下的事情他就不用操心,全让邮局给他办了。这样,不管对方是什么语言开发的系统,只要他们采用统一的消息格式,java开发的系统也就能够和C++, .net等平台的系统通信了。
    • 消息的可靠性:我们具体发送消息的任务相当于交给了消息队列。所有提交的消息有消息队列里的message router来投递。这有点像网络概念里的路由器一样,根据一个发送方指定的地址并转发到另外一个地方。同时,消息队列也根据不同的需要将消息进行持久化,这样保证消息在投递的过程中不会被丢失。
    • 系统可靠性:如果对消息队列和RPC的方式做一个对比,这就好比是生活中打电话和发短信的区别。在打电话的时候,我们是必须期望接电话的对方在电话旁边能够接收响应。而如果接收人不在或者忙的话,打电话的这一方就只能在这里干等。这就是系统不够健壮的地方,一旦另外一方系统出故障,系统就没法正常运作。而且要保证能够正常通信,需要系统双方都同时就位。而发短信的这种消息方式则不然,消息可以准确的送达到对方,如果对方暂时忙消息也会保存在那里。等有空的时候会进行回复。至少保证了有效信息的传递。这种特性也就是保证了系统的异步执行,从某种角度来说也提升了系统性能。

        综合上面的这些讨论,消息队列算是一种兼顾了性能、可靠性和松耦合的一种理想集成方式。目前实现消息队列的产品有很多,比如微软的MSMQ, 开源产品ActiveMQ, RabbitMQ, ZeroMQ等。后续的文章还会对消息队列的应用和内部机制做深入的分析。

    总结

         应用系统集成的方式有很多,最常见的几种有文件传输,数据库共享,远程方法调用以及消息队列。他们在解决某些特定领域的问题时有自己的特长。综合来说,消息队列算是一种比较理想的解决方案。不同事物或者不同领域之间也有很多的相似性,在研究消息队列的时候会发现他们和网络的体系结构思想非常相似。

    展开全文
  • 企业微信---第三方应用开发 笔记

    万次阅读 热门讨论 2020-07-02 10:59:45
    这里的CorpID是第三方供应商供应商的企业ID,不同于企业微信的CorpID。 ProviderSecret:还未用到,之后再补 系统事件接收URL:保存之前腾讯的企业微信服务器会发送一个Get请求到这个地址,所有要准备一台服务器,...

    跳坑记录

    要成为第三方供应商,先按开发文档步骤操作。服务商注册应用。也可以申请个企业微信帐号,然后成为服务商(可以做测试,但应用不能上线)

    1,注册成功后,配置开发信息:通用开发参数

    这里的CorpID是第三方供应商供应商的企业ID,不同于企业微信的CorpID。 ProviderSecret:还未用到,之后再补
    系统事件接收URL:保存之前腾讯的企业微信服务器会发送一个Get请求到这个地址,所要要准备一台服务器(也可以用内网穿透工具实现),接受这请求,并做URL验证。
    验证URL有效性

    Token、EncodingAESKey:这个Token+EncodingAESKey+腾讯微信服务器的Get请求的QueryString,一起来解密Get请求的密文,并返回明文,解析正确并Response.Write(明文),也就验证URL成功了。

    这里写图片描述

    2, 创建应用,并配置

    SuiteID:指令回调URL 解密时使用。数据回调URL解密时使用的是安装第三方应用的授权方的CorpID。如果错误,解密会返回40005
    错误的CorpID。

    Secret:和SuiteID一起用来获取应用授权Token

    这里写图片描述

    应用主页:要设计的应用主页 可信域名:还不清楚,之后再补 业务设置URL:安装第三方应用的企业(授权方)管理员进入应用后台配置的URL
    数据回调URL:这里也是要先验证,与前面的系统事件接收URL验证方式一样,要处理腾讯企业微信服务器的Get请求并返回解密后的明文,验证后,处理接收消息时是POST请求
    指令回调URL:使用时感觉就是接收Event的,指令理解为事件更好理解吧。与前面的系统事件接收URL验证方式一样,要处理腾讯企业微信服务器的Get请求并返回解密后的明文,验证后,处理接收消息时是POST请求

    这里写图片描述

    应用主页配置

    前面未对应用主页说明,自己在学习中也遇到诸多问题,问题列表与解决办法:

    1. 自定义菜单怎么在应用主页上显示?:到目前没解决。如果是企业应用而不是第三方应用的话,只要不设置应用主页,在进入应用时直接回显示自定义的菜单。
    2. 怎么将授权方和我做的第三方应用联系起来? 这个问题搞了两天才大概的了解 :
      1. 先仔细阅读开发文档 链接1网页授权登录 ,链接2网页授权登录第三方
        。要清楚了解链接1中的 OAuth2.0接入流程说明,因为是做的第三方应用,链接2页必须要仔细阅读。
      2. 了解后发现,之前的应用主页设置的有问题,应用主页要写成下面的形式(可能不完全正确),redirect_uri的域名一定要与【可信域名】一致,如果可信域名是二级,这里也要设置为二级域名。
      3. 以上两点了解后,参考 企业微信第三方应用配置
        ,终于能将 企业微信和第三方应用串联起来了。
      4. 第三方应用里,想要创建主菜单、二级菜单、view菜单、click菜单怎么做?:貌似全要由第三方自己实现了。前面说了,非第三方的企业应用只要不设置主页就可以直接使用企业微信后台设置的自定义菜单

    第三方应用里的自定义菜单的界面是当有消息时才会看到,不是用来设计应用,而是作为第三方应用的入口:比如点选哪个菜单跳转到第三方应用的那个网址、点选哪个菜单执行拍照、图片选取、录音什么的。但第三方应用要求必须设置应用主页,菜单不就显示不出来了。
    这里写图片描述

    展开全文
  • 钉钉微应用接入(企业内部开发)

    万次阅读 2017-07-18 14:45:44
    获取企业号CorpID&Secret: 登录钉钉OA管理后台-微应用-工作台设置(仅企业主管理员可查看)应用...创建微应用: 进入钉钉管理后台后可以进入 “企业应用-应用管理” 页面创建微应用。 需要填写应用Logo、应用名称、功能介

    文档中心

    https://open-doc.dingtalk.com

    钉钉后台配置

    创建微应用流程:

    这里写图片描述
    获取企业号CorpID&Secret: 登录钉钉OA管理后台-微应用-工作台设置(仅企业主管理员可查看)

    应用开发流程

    1. 注册企业: 进入OA管理后台,通过一系列流程,完成企业注册。
    2. 创建微应用: 进入钉钉管理后台后可以进入 “企业应用-应用管理” 页面创建微应用。
      需要填写应用Logo、应用名称、功能介绍、首页地址等必填信息。完成后,可在钉钉App的“工作”Tab下找到企业,可以查看到微应用入口。
      • 注意:首页地址必须真实有效,否则无法正常访问
      • 创建微应用后会生成AgentID,方便后续开发使用。AgentID可用于免登鉴权、发送企业会话消息等场景。
    3. 开发微应用:
      • 获取企业的CorpID和CorpSecret(OA后台可以查看到)
      • 获取AccessToken
      • 获取js_ticket
      • 通过jsAPI获取免登码

        点击小标题链接到详情地址

    应用Demo源码

    下载源码
    1. 配置CorpId和CorpSecret到Env.java中
    2. 使用IntelliJ IDEA开发工具使用Tomcat部署工程(可参阅IDEA搭建Web工程
    3. 将地址配置到微应用中即可。

    移动端开发文档

    请在页面引入js文件:
    http://g.alicdn.com/dingding/open-develop/1.5.1/dingtalk.js

    或者

    https://g.alicdn.com/dingding/open-develop/1.5.1/dingtalk.js

    引入dingtalk.js会得到一个全局变量dd,支持amd、cmd引入方式
    Note:js文件版本在添加升级功能时地址会变化,如有需要(比如要使用新增的js-api),请随时关注地址变更。但是旧版本js文件也将一直可用。

    JSAPI

    对钉钉容器的H5开发者来说,钉钉提供了一些Native能力的jsapi,这些api有很多是手机的基础能力,对这些api的调用不需要进行鉴权(即不需要进行dd.config),只需要保证在dd.ready里面调用即可。对于一些钉钉业务相关、安全相关的api调用,我们需要开发者先进行鉴权再进行调用。

    JSAPI鉴权的正确使用方式

    dd.config({
        agentId: '', // 必填,微应用ID
        corpId: '',//必填,企业ID
        timeStamp: , // 必填,生成签名的时间戳
        nonceStr: '', // 必填,生成签名的随机串
        signature: '', // 必填,签名
        type:0/1,   //选填。0表示微应用的jsapi,1表示服务窗的jsapi。不填默认为0。该参数从dingtalk.js的0.8.3版本开始支持
        jsApiList : [ 'runtime.info', 'biz.contact.choose',
            'device.notification.confirm', 'device.notification.alert',
            'device.notification.prompt', 'biz.ding.post',
            'biz.util.openLink' ] // 必填,需要使用的jsapi列表,注意:不要带dd。
    });
    
    
    dd.ready(function(){
        ;
    });
    
    
    dd.error(function(error){
           /**
            {
               message:"错误信息",//message信息会展示出钉钉服务端生成签名使用的参数,请和您生成签名的参数作对比,找出错误的参数
               errorCode:"错误码"
            }
           **/
           alert('dd error: ' + JSON.stringify(err));
    });

    Demo和调试工具

    我们提供了Demo和调试工具给您的开发提供方便,如果对调用参数有疑问,请使用调试工具。对jsapi用法有疑问,可查看Demo.

    调试工具:http://wsdebug.dingtalk.com
    打开左边的超链接之后,手机扫描二维码,然后在PC页面上配置jsapi参数,点击执行手机就会给予相应反馈

    微应用Demo地址:https://github.com/outlookxie/app-todolist

    展开全文
  • 钉钉企业应用调试方法

    万次阅读 热门讨论 2020-08-20 12:38:53
    解决钉钉企业应用需要反复部署调试的方法(钉钉企业应用调试方法) 启动你的本地项目(前提要后端允许本地的id地址访问) 首先下载钉钉RC版,加QQ:1336791007免费领取(备注,求钉钉RC版) 进到RC版的钉钉点击...
  • 微信企业号自建应用

    万次阅读 2017-03-09 15:49:32
    企业号管理端【应用中心】默认有1个自建应用企业小助手)和2个基础应用(微企通讯录和移动管理助手)。 1、企业小助手是企业号下默认添加的应用,它用来向用户发送企业号的系统消息: 1)成员关注:向微信侧...
  • 现在需要开发一个内部使用的钉钉微应用,我拿h5开发可以吗,开发完要怎么部署或者放到钉钉上面呢
  • 链接:https://pan.baidu.com/s/1KgZA_vHcQPYFH7xOY7zOxg 提取码:5qam
  • 钉钉小程序学习笔记

    万次阅读 2019-02-22 17:23:31
    一、钉钉E应用与微信小程序 二、应用类型 E应用 E应用是一种全新的开发模式,让移动开发者通过简捷的前端语法写出Native级别的性能体验,并支持iOS、安卓、等多端部署 ...企业内部开发的应用无...
  • SpringBoot企业应用实战

    万次阅读 多人点赞 2019-09-22 17:05:56
    SpringBoot企业应用实战 基础教程 SpringBoot 快速入门 SpringBoot快速入门,不继承SpringBoot父依赖项目 SpringBoot集成MyBatis SpringBoot热部署 SpringBoot整合freemarker SpringBoot整合模板引擎...
  • 《Java EE企业应用开发教程》源码

    千次阅读 多人点赞 2020-04-23 20:25:17
    将《Java EE企业应用开发教程Spring+Spring MVC+MyBatis》整本书全部源代码分享给大家。 链接: https://pan.baidu.com/s/1SZQ1wHvCTDa_2IIgOqj4QQ 提取码: hwhb(永久有效) 请不要让好资源被埋没,谢谢! ...
  • 架构简述—兼谈应用软件的症结之一

    万次阅读 多人点赞 2012-02-09 09:22:40
    摘要:企业应用架构、企业技术架构 参阅:序 消灭人狼 软件的十大命题 编程规则    架构、架构、架构!  各领域都在谈论架构,尤其在软件领域,架构师也似乎成了软件士兵向往的将军头衔。 然而,目前架构...
  • 摘要: ...从传统企业应用和互联网企业应用的不同特点说起,讲述传统企业架构升级微服务 过程中的一些重点关注的内容、方法和建议。 3. 传统SOA和微服务差别在哪:运行期的快速变更能力不同 讲...
  • 微信企业号/企业微信的corpid和secret

    万次阅读 2017-04-12 15:54:30
    如果要进行微信企业号和企业微信的开发,首先必须知道对应的corpid和secret,因为很多API调用都必须使用这两个参数。典型的API如获取AccessToken的API。下面介绍在哪里查看微信企业号和企业微信的corpid和secret。 ...
  •  企业微信第三方应用企业微信自建应用也不相同,一定要区分! !! 本地测试完成,没问题了,直接提交上线,就OK啦!!!1.官网地址:https://work.weixin.qq.com/,首先(注册/)登陆,然后点击右上角,服务商...
  • 各种系统架构图与详细说明

    万次阅读 多人点赞 2020-04-19 18:26:04
    本次项目的一项重点就是实现原有应用系统的全面升级以及新的应用系统的开发,从而建立行业的全面的应用系统架构群。整体应用系统通过SOA面向服务管理架构模式实现应用组件的有效整合,完成应用系统的统一化管理与...
  • WPF 高质量教程(转载自圣殿骑士)

    万次阅读 2016-09-30 12:54:32
    WPF 基础到企业应用系列1——开篇有益 http://knightswarrior.blog.51cto.com/1792698/343871 WPF 基础到企业应用系列2——WPF前世今生 http://knightswarrior.blog.51cto.com/1792698/344622 WPF 基础到企业应用...
  • win10企业版2016长期服务版是目前最新的win10系统版本,扩展支持周期比其他的版本支持周期要延迟1年,精简掉了许多系统自带软件,比如Edge浏览器、小娜,无磁铁。更新周期不那么频繁,只更新漏洞补丁,可自选...
  • 注:本文转自 ... ...之前我们都知道可以将应用程序发布到Windows ...如果我们是企业开发人员,则我们的应用可能属于以下两种类别之一: 1.应用内容是只与公司内个人切实相关的应用。 2.希望尽可能多的用户可以
1 2 3 4 5 ... 20
收藏数 957,509
精华内容 383,003
关键字:

企业应用