OptaPlanner Right制造订单调度工具
您是否认为OptaPlanner是规划具有多层次工艺路线（最终产品、子装配1、子装配2、子装配11、子装配12等）的制造操作的正确工具？
我们讨论的是1000个生产订单，每个订单有10-20个操作。
我知道，看起来像项目车间调度。我只是关心数据量和在合理时间内找到最佳解决方案的能力...
对于这个问题域和OptaPlanner，有真实的例子吗？
共有1个答案
请参见项目作业调度示例。这不是我们最简单或最漂亮的例子，但它有效，你可以让它变得漂亮。
对于缩放，如果它最终会成为一个问题（我怀疑它只有1k实体），有大量的电源调整选项（多线程求解，分区搜索，...）
-
我们使用标准的“层控件”从传单。实例化如下： 层是按随机顺序动态添加的（取决于xhr请求完成的时间）。然而，似乎Laflet implicity使用相应层的_leaflet_id在层控件中排序，因此我们的层以随机顺序出现。 有没有办法告诉传单应该按哪个顺序显示控件中的图层？例如。通过在调用或方法时传递一些附加参数？ 单张版本为1.0-dev
-
接收订单状态回调 说明 当订单状态发生改变时，滴滴出行会通过回调服务将这些事件通知接入方。使用此功能需开启回调服务，关于如何设置接收消息请见回调服务配置。 当接入方收到回调后，需要重新调用订单详情接口，拉取最新的订单状态和信息，然后做相应处理 支持场景 订单中间状态流转 司机接单(等待接驾) 改派中 乘客迟到 乘客迟到计费 司机迟到 司机到达 计费中（行程中） 订单终态通知 正常
-
统一下单 没错，什么 H5 支付，公众号支付，扫码支付，支付中签约，全部都是用这个接口下单。 {info} 参数 appid, mch_id, nonce_str, sign, sign_type 可不用传入 服务商模式下, 需使用 sub_openid, 并传入sub_mch_id 和sub_appid $result = $app->order->unify([ 'body' => '
-
作用 接入方或者费控平台拉取企业支付订单或个人支付转个人垫付订单，做汇总统计之类 依赖 暂无依赖 注意 所有接口调用时需要严格遵守请求方式(GET/POST) 使用接口前需要仔细阅读每个接口的注意事项 接口报错时先阅读通用错误解决方案和当前接口文档下的接口错误解决方案
-
问题内容： 我想创建一个发布-订阅基础结构，其中每个订阅者都将收听多个（例如100k）频道。 我认为可以将Redis PubSub用于此目的，但是我不确定在这里订阅数千个频道是否是最佳实践。为了回答这个问题，我想知道Redis中的订阅机制在后台如何工作。 另一种选择是为每个订户创建一个频道，并在两者之间放置一些组件，该组件将获取所有消息并将其发布到相关的频道。 还有其他想法吗？ 问题答案： Sal
-
3.1 下订单 3.1.1 描述 通过调用该接口为指定电话号码充值指定流量 3.1.2 请求地址 地址:https://api.bokecs.com/recharge/createOrder 3.1.3 请求方式 POST 3.1.4 请求参数 1) 请求入参 { "mobile": "18514428123", "flow":"3000", "range":"1" }