Jettrac_Modules_CityScape

What is JetTrac?

JetTrac is an all inclusive term for the family of JetTrac modules, services, and graphical interfaces we have developed over the last 20+ years.

The three main components of JetTrac are:

1. The JobController, POP3Scanner and GMailMonitor Windows services

2. The graphical interfaces of JetTrac JobConfig, JetTrac Dashboard and the Google Forms based interfaces for dispatching Field Service

3. The 100+ JetTrac modules that provide a rich and varied functionality

The JobController service, put simply, is a shell that is configured to run “Jobs” which are a list of modules to run, how to run them, and the order in which to run them.

The modules themselves provide the functionality to each job step.

 

For example, if you wish to have a fillable PDF form with some prepopulated data emailed to a technician outside of the office you might set up JobController to run JetTrac PDFMerge and JetTrac Email as two steps in a job. The JetTrac PDFMerge module takes data and merges that into a PDF form, while the JetTrac Email module sends an email with the PDF form attached.

These are only two examples of an ever growing library of modules, each providing different capabilities.

In addition, we have developed services and graphical interfaces which expand the functionality of JetTrac and make it easier to use. Some of this functionality includes easy error reporting, pulling files directly from an email account, and a user friendly way to set up jobs.

Background of JetTrac Phase 1 from 1994-2003

ProTechnology has been a JetForm/Accelio/Adobe partner since 1994 with a strong focus/emphasis on JetForm/Adobe Central (will be referred to as Central in this document) implementations.  In about 1998 ProTechnology saw the need to create additional functionality for Central implementations. Adobe Central’s data transformation (JFTrans) and merge engine (JFMerge) were very good however customers were demanding specific functionalities that Central could not do.  Because of the open architecture of the Adobe Central system, specifically the Job Management Database ProTechnology started developing what were known as “Custom Agents”. Our first JetTrac module was JetTrac Email in 1998 and it has been implemented for many hundreds of Central and JetTrac installations to this day.

Between 1998 and 2018 ProTechnology developed over 150 JetTrac modules that do all sorts of functionality (details are in other documents).  Some of these modules were “one offs” for specific Central customers and did not have general applicability across multiple customers. A real focus was on creating modules with specific purposes but could “plugged in” to any Central installation that needed that functionality.

From the beginning there has been an underlying philosophy and goal with ProTechnology’s JetTrac development to make it as easy as possible for customers and partners to implement JetTrac solutions and specifically with no scripting or programming.  In 2016 ProTechnology put this philosophy into a motto “JetTrac Does The Heavy Lifting So You Don’t Have To” (explained further below).

Most JetTrac modules in Phase 1 were developed in Java so they could be implemented across many platforms.  This is because our Central customers implemented on Windows, Linux, Unix and AS/400/iSeries.

JetTrac Phase 2 from 2003-2012

In the 2003-2005 timeframe ProTechnology felt that the “writing was on the wall” for Adobe Central and that someday Central was going to be sunsetted.  ProTechnology had about 200 JetForm/Adobe Central customers that saw ProTechnology as their trusted document generation provider and we wanted to ensure that these customers had the best solution possible if and when Central was sunsetted.

In 2005 ProTechnology wanted to provide an alternate solution for both Central customers and new customers so we developed a module named JetTrac JobController which has the same functionality as the Adobe Central Service.  JobController was written in Java so can run on other platforms other than Windows. JobController was written to be a “plug replacement” for Adobe Central so it reads a jfserver.ini configuration file and a jfserver.jmd (JMD or Job Management Database) so a migration from Central to JetTrac could be as quick and simple as possible.  This laid the groundwork for JetTrac Phase 3.

JetTrac Phase 3 from 2012-present

Up to 2012 ProTechnology was still totally focused on production document generation solutions.  However in 2012 ProTechnology started seeing the need for for clients to automate their paper forms to electronic forms on mobile devices (tablets & smartphones).  This was really starting to be a possibility with the introduction of the iPad in April 2010 (and Android tablets in 2009).

In late 2012 the founder of ProTechnology had an “Ah Ha” moment when he had termites in his home and called in two different termite companies who came out and did measurements then took 1-2 weeks to deliver a proposal.  We came up with the idea to automate the proposal process to be real-time so when the sales/service personnel was in the field, they could collect the information electronically and submit it back to a server that would take all this data and create a proposal that would be sent back to the sales/service person in the field, all within about a minute.  The sales/service person could then present the proposal to the prospect, get an electronic signature and close the sale right when they were on the spot.

That day the founder sat down with one of ProTechnology’s developers and gave him a challenge to develop an easy way to merge data with a PDF form, extract data out of PDF forms, combine multiple PDF forms together, bookmark PDF’s and many other functionalities that ProTechnology has developed in this timeframe. Adobe was already doing similar things to this with their Adobe LiveCycle Suite but the price point of the software and complex, expensive services required to develop these solutions, put them out of reach for the majority of ProTechnology prospects.  ProTechnology made the decision to heavily invest in the development of JetTrac solutions specifically around mobile data capture but with a reasonable price point.

JetTrac positioning as JetTrac Field Service

Over the last six years ProTechnology has developed a core group of about 50 JetTrac modules that all have to do with mobile data capture in field service and sales (as one example of use cases).  ProTechnology has been very serious in its efforts to make it as quick, simple and easy as possible to implement quite sophisticated business processes.

As customers come up with new requirements ProTechnology determines if these requirements can be met with one of more existing JetTrac modules.  If not then ProTechnology will analyze the requirements and determine if a new JetTrac module can and should be developed to provide that functionality.

JetTrac is extremely useful for any organization that sends service or sales people outside the office to collect data.  If these organizations are doing this now with paper forms then they are ideal for implementing a JetTrac solution.

ProTechnology has worked extensively with “contractors” like electrical contractors, plumbing contractors, etc. to automate their business processes of sending out e-forms, collecting, processing and submitting data.

Here are some other examples of how ProTechnology has also implemented JetTrac:

  1. For a materials handling company HQ’d in Chicago that has 200 technicians that service forklifts.  All paper forms have been automated to PDF forms and JetTrac pre-populates known data into a Work Order and other related forms and emails them out to the technicians.  The technicians often work in warehouses that are metal buildings with no internet access so having intelligent PDF forms that work offline was absolutely critical. The technicians fill out all required data and submit back via email.  JetTrac then extracts the data and kicks off an email-based workflow to a department that reviews and approves (or rejects) the forms packages. JetTrac gets back the approved or rejected PDF forms package and kicks off other jobs (based on the status) that extract the data and sends it to their ERP system, flattens the PDF and emails it to the customer, etc.

  2. For a company that installs video surveillance systems in businesses.  This company subcontracts service work to other people and they use JetTrac to enter all related data pertaining to the work they are doing and those forms/data then flows back to the main companies system and kicks off workflows.

  3. For a medical company that sends Nurse Practitioners (NP) to patients home after the patient has been discharged from the hospital.  The NP’s records in a PDF form package a large amount of data about the patients health and submits that back to the medical company.

  4. For a company that installs and services water heater and boiler systems in the Midwest U.S.  Technicians are dispatched Work Orders electronically and they fill out relevant data, take photos, capture signatures, etc.  These forms are then emailed back to JetTrac’s POP3Scanner and processed through JetTrac that then extracts data, photos, etc. and sends it back to their ERP/accounting system for further processing.   

JetTrac integration with Google

 

ProTechnology has done extensive integration between JetTrac and Google using the Google API’s.  The reason that ProTechnology has spent so much time and money on this integration is because we want to be able to scale from small companies (like small electrical contractors) to large companies.  Small companies don’t have the money to invest in costly document management systems and other kinds of ERP/CRM/accounting systems. Google provides many capabilities free of charge that are very useful to small to medium size companies.  Here is a high level overview of our JetTrac integration to Google:

  • JetTrac PushToGoogleCalendar - from a production JobController job that does a dispatch to a field person this module programmatically adds Google Calendar events to the technicians calendar with the appointment date and time, addresses (that the tech can get turn by turn directions from Google Maps) and unlimited details in the Reference section.  We can also color code specific calendar events.

  • JetTrac PullFromGoogleCalendar - from a production JobController job we can pull specific information from Google Calendar events.  This could be for use cases where the technician records job information directly in their Google Calendar and JetTrac can pull this data and send it to another system for further processing.

  • JetTrac PushToGoogleSheets - from a production JobController job we can push data from the XML to specific Google Sheets with total control over which tab we are pushing the data to and where we are pushing it.

  • JetTrac PullFromGoogleSheets - from a production JobController job we can pull data from specified Google Sheets directly to XML then we can send it to another system for further processing.

  • JetTrac ClearGoogleSheets - typically used to clear a Google Sheet after JTPullFromGoogleSheets has already pulled the data.  This has been used for timekeeping solutions.

  • JetTrac PushToGoogleDrive - from a production JobController job we can programmatically upload documents (PDF’s or any other type of document) to specified folder structures in Google Drive.

The graphic below illustrates the modularity of JetTrac.  JobController sits in the middle and is the Controller (thus JetTrac JobController) of production “jobs” that run on a server.  The 50+ core modules are in the four categories below of PDF, Data, Email (and other transport mechanisms) and Google.

The graphic below further illustrates the modularity of JetTrac.  If you consider JetTrac modules like Lego blocks, you can plug together Lego blocks to make a plane, a race car and pretty much whatever you like.  You can do the same thing with plugging together JetTrac modules using JetTrac JobConfig (more on that on the next page) with NO SCRIPTING OR PROGRAMMING (because JetTrac does the “Heavy Lifting”!

JetTrac  as a Platform

JetTrac can be configured to be used as a fully customizable platform that can fit any business needs a company might have, or can be configured as a prebuilt solution with job steps predefined to meet the needs of a specific vertical market. The benefit of the prebuilt solution is that “out of the box” very little configuration needs to be done before having a fully functional solution. Whereas the benefit of marketing the JetTrac platform as a whole allows for complete customization to meet any needs a company has.

The graphics below illustrate the prebuilt solution vs the platform as a whole:

Prebuilt to fit a specific vertical market. All the pieces necessary for specific functionality

Platform with all the pieces necessary to fit any need

JetTrac Controller

The purpose of this section is to give you an idea of what JetTrac is actually doing on the server.  JetTrac JobController runs as a Windows service and monitors a watched folder for transaction files to drop in that JobController then processes as a production job.  JobController determines what job to run based on either a job card in an XML or Field Nominated (Central .dat) file OR based on a file extension or filename pattern OR based on a pattern matching within the data file itself.  All this is built into JobController.

Once a job is triggered then JobController runs that job according to the Job definition set up in JetTrac JobConfig (and saved in a JMD Job Management Database).  Each step of the job is run in sequence until the job completes successfully or errors out.

An integral part of JobController is detecting when there is an error in any step of a job.  What happens if there is an error is controlled for each job step, whether the job should continue or error out.  If it errors out then a special job named JBCError is triggered automatically that can notify an administrator of the error.  If JetTrac Dashboard (explained below) is used then the Dashboard GUI itself will be notified of the error visually and audibly.

Each instance of JobController is single threaded meaning that one job will process at a time in that thread until that job completes (successfully or with an error).  The next transaction file will then be processed. You can set up multiple instances of JobController on the same server or on different servers and if desired they can all (or part) be load balanced by implementing JetTrac InstanceBalance.

Custom JetTrac Modules

ProTechnology made the decision to keep a similar architecture to what Adobe Central always had of an open architecture that custom modules could easily be plugged in.  ProTechnology publishes a document (three pages) that explains exactly how a customer or partner can develop their own custom modules that can easily plug into JetTrac. Over the years ProTechnology has had a number of customers and partners that have developed their own custom modules.  Every one of these customers and partners have been amazed about how easy it is to do this.

JetTrac graphical interfaces

In keeping with our goal to make JetTrac implementations as quick, easy and simple as possible we have developed two powerful graphical interfaces:

JetTrac JobConfig

JobConfig was developed in 2013 as a way for whoever is responsible at the customer or partner for the JetTrac implementation to easily create and modify production JetTrac jobs using a graphical interface.  It has been enhanced over the years to be extremely simple to use. Here is one screenshot:

JetTrac Dashboard

JetTrac, like Adobe Central is a “black box” on a production server.  The detailed log in Central and JetTrac is too verbose and not user friendly for end users.  Dashboard was created to allow a non-technical person to have a very customized view into the production job processing in JetTrac.  Here is a sample screenshot:

The information written to JetTrac Dashboard is controlled by the job definition in JetTrac JobConfig.  Within a job, whenever you want a notification written to the Dashboard you simply insert a JTLog step and control what is written to the Dashboard with a combination of fixed strings and variable data using JobController variables.

You will notice there are three parts to the Dashboard.

  1. The top section titled “Email inbox monitor” is monitoring a Gmail POP3 address and whenever an email arrives in the inbox a line will be written to this section.  This is controlled by a Windows service named “JetTrac GMailMonitor”.

  2. The middle section titled “Retrieved Emails” is controlled by a Windows service named “JetTrac POP3Scanner” that actually retrieves qualifying email attachments and delivers those files to the watched folder of JobController.

  3. The bottom section titled “JetTrac Processing Window” is controlled by the JetTrac job definition when a module named JTLog is called.

Note: the Dashboard interface is controlled by a queue file.  There is a “Writer” (GMailMonitor, POP3Scanner and JTLog) and a “Reader” (the JetTrac Dashboard itself).  This allows for a real-time window into what is actually processing in JobController.

JetTrac - where it runs and how it is licensed

ProTechnology owns all the intellectual property for JetTrac so has flexibility on how JetTrac is licensed and where it is run as described below.

Some parts of JetTrac are developed in Java and could run on platforms other than Windows however let’s assume that most installation of a full JetTrac implementation will be run on Windows.  It doesn’t matters where the Windows environment is - on-premise or hosted in the cloud, e.g. AWS, Azure, etc.

JetTrac can be licensed in two primary ways:

  1. Subscription - licensed on a monthly subscription basis and billed on a calendar quarterly basis.  The subscription amount is based on several factors as outlined below.

  2. Perpetual license - a one time perpetual licensing fee plus annual maintenance and support.  The perpetual license can be based on several factors as outlined below.

One of the goals that ProTechnology has is to be able to scale the licensing costs from small companies to large companies.  The more JetTrac that is “eaten” provides more benefit to the end user.

JetTrac is normally licensed by a number of transactions allowed per year.  If a small company has a small number of transactions per year they should pay much less than a large company that has a very high volume of annual transactions.

In certain circumstances JetTrac could also be licensed per server with unlimited transactions.

There is one other factor that needs to be considered.  Since JetTrac is very modular, if a customer implemented just a couple JetTrac modules vs. a customer that implements the full suite of JetTrac modules for the same transaction volume they wouldn’t necessarily pay the same amount.

JetTrac has a licensing control to ensure that when JetTrac is running on a computer there is a proper license for it.  The licensing system can restrict to specific modules and for specific dates. This is how we control the subscription licensing.  If a customer stops paying the quarterly subscription amount, their JetTrac solution will stop working after a specified date. JetTrac will notify subscription customers via email if their subscription period will be ending soon.  This is totally controlled by the JetTrac jobs that are set up on the JetTrac server.

John D’Aintree, ProTechnology’s VP of Sales, Marking and Partner relationships can work with partners and customers to come up with the most fair licensing for all parties.

Note: when JetTrac is licensed for a specific number of annual transactions, those transactions are tracked and reported on a monthly basis to the partner and/or the end user.  Here is a sample of a JetTrac Transaction Summary: