Everest Automation & API’s
Author: [andrew shelton](/content/author/mt360andrew/ "Posts by andrew shelton"/index.html)
Date: 2020-09-02T10:08:14-04:00

Automate Business Processes to Gain Efficiency & Profitability

Identifying opportunities for digital transformation through business automation can significantly streamline operations and reduce pain points. MARTEC360 has decades of successful business automation solution experience with hundreds in the Everest ERP ecosystem. The examples below are intended to show some of the possibilities on eliminating manual processes in your business.

Examples:

  • Order Import Systems (OIS)
    • The OIS by MARTEC360 can connect to nearly any order management system data source and streamline the customer/order import processes. Examples of various order management systems may be EDI, E-Commerce sites, Marketplaces (via a secondary middleware), CRM platforms or other external order management systems.
  • Customer Statements
    • Auto-generate PDFs on X day of each month and generate CRM email notifications to accounts receivables customers. The net result is the savings of thousands of hours and expense annually in processing the statements and mailing them out.
  • Automated Sales Order Invoicing
    • Identify workflows where sales orders can auto convert from sales order to sales invoices. An example would be this would be Amazon FBA orders which auto-import and need payment applied and to simply be invoiced to clear them out of open orders. Another example would be any time a sales order has shipment tracking numbers on them and is a single shipment order.
  • Automated Purchase Order Generation
    • Based on YoY sales or inventory trends, auto generate stocking purchase orders to back fill inventory. Another scenario which the MARTEC360 team has repeatedly automated in the past relates to drop-ship or JIT POs based on sales orders and inventory levels.
  • Automated Sales Order Creation
    • Recurring subscription businesses (wine clubs, magazine subscriptions, or any consumable subscriptions) where a template may be configured for the ‘order template’ may be auto generated each day/week/month/quarter/year based on the template settings.

It is important to note that API/SDK automation solutions may be adversely impacted by improperly configured server/networking environments. We advise accounts go through an audit on their business environment to ensure everything is properly optimized and the appropriate resources are in place. Please see our business support services for more details.

API/SDK FAQ’s

How are SDK/API projects handled?

Typically there is a scope of business support hours by either block-time (available in increments of 10, 20 or 40 hours) or a compiled project in order to fully identify and document the business requirements (BRD) of the solution. In many cases where we already have SDK/API applications already pre-built for the desired automation goals, the discovery scope is less time or level-of-effort (LOE).

At the conclusion of the discovery session a BRD will be generated along with a proposal.

Most SDK/API business automation applications which are then integrated all fall into Software-As-a-Service (SaaS) add-ons and are billed either monthly or annually along with any associated setup fees. Unless the support requests are edge cases, most maintenance and support is built into the SaaS pricing.

What does the typical price of a SDK/API automation app cost?

The pricing can vary greatly. Is it for a single company or is it multi-company? Does the application need to support multi-company individually or does it need to be multi-tenant? Is it something which is a proven/heavily used application such as the OIS?

Are there any minimum/suggested requirements for API/SDK or 3rd party connector implementations?

Yes. Through our 20+ years of building solutions, supporting customizations and providing professional services to the Everest community we have found a number of non-documented best practices. See below for a brief list of these. If you are interested in exploring performance or stability issues in your own instances, please reach out and schedule a consult and/or business support services. Many of these start by having a properly configured and optimized Everest ecosystem – specifically, the right number of application servers and hardware/software requirements.

For simplicity, we will refer to any combination of SDK/API’s, 3rd party connectors or customizations as “application”.

Best practices:

  1. Make sure you have an application server besides the database server for any application. That way if the Everest COM+ application layer goes down in any instance, you’re not left having to perform ugly reboots in the middle of the day.
  2. Ensure all of your Everest users have a separate Everest COM+ application server rather than using the database server as such during the standard login process. This is so that should the COM+ layer have any problems due to user activity, it doesn’t crash the database server COM+ layer and thereby knock out your application automation solution.
  3. Ensure there is a Windows user/pass which is set for non-expiry so that the application doesn’t crash/stop working when the password expires.
  4. Ensure that there is a non “SA” SQL user account which the application is set up to use so that in SQL, if one needs to track application/memory leaks, they are more easily identifiable. Our recommendation is to typically have a different SQL user for each type of application.
  5. Ensure the application is properly opening and closing Everest SDK user sessions/tokens. We have seen MANY cases where orphaned sessions are left open. When left open they will consume the seats and eventually cause new SDK/API sessions to fail due to “too many users”. These are not as easy or straightforward to resolve as they must be reset from the database backend rather than any windows GUI.

How much hardware should I have for a SDK/API processing server?

The simple answer is it depends. How fast do you want the activities to process? There should be ~8gb of memory or thereabouts (more if running multiple applications throughout the day). The SDK/API application is largely CPU dependent though. Throwing more CPU’s at it in our experience does not move the needle a great deal. The faster the CPU, the faster the applications can get into the code, execute the process, close the connection and then loop through the sequencing.

An example from an account which has used our OIS application for years: They were on a dual-core, 1.8GHz processor server for a long time. They upgraded into our AWS Private Cloud for Everest and r5n.large instance which has a sustained dual-core, 3.1GHz processor. The processing speed for OIS on a typical batch of 500 orders importing was cut in half. Instead of taking 2.25 hours for processing, the imports took just over an hour.