F4311FSBeginDoc 0001 Record Invalid

F4311FSBeginDoc 0001 Record  Invalid

I spent far too long today trying to solve the following response from F4311FSBeginDoc:

<error code='0001'>Error: Action Invalid</error>
<error code='1456'>Warning: Not in Original Mode of Entry    WARNING</error>

TL;DR: F4311FSBeginDoc szOrderSuffix must  always be "000", even when making change orders.  The F4311EditLine szOrderSuffix values will use the proper number, such as "001", "002" et cetera.


Our integration code in C# uses the following Master Business Functions when making a Subcontract/PO change order:

F4311FSBeginDoc
F4311EditLine (for each line)
F4311EditDoc
F4311EndDoc

They are pretty straightforward to use, especially compared to writing AP or AR invoices.

But today I was refactoring and testing some code and suddenly I could no longer make change orders!

Whenever I posted to F4311FSBeginDoc, I kept getting 0001 Action Invalid, and 1456 Not in Original Mode of Entry.

What the heck?  The code I was modifying  had been working for years, and was working fine just a few days ago.   But I was re-implementing the mappings in what I felt was a simpler structure that more clearly separated the data which is meaningful to end-users versus the "housekeeping" data such as mnJobNumber, szComputerId, and all that jazz.

After a few very frustrated hours, which included rebooting my JDE application server multiple times and diving deep into jdeDebug logs, I found the answer.  Sadly, the answer was sitting in the code which I had originally copied my new code from:

begin.Params.szOrderSuffix.Value = "000"; // f4301.phSFXO; this must always be 000

Through all those hours of testing, delving, pulling my hair out, I had managed to miss this comment.  Granted, that comment could have said a lot more, but once I saw it, it was painfully obvious.

Why painfully?  Well, this particular method was written sometime in mid 2016.  Its predecessor, in yet another version of the code, was written in 2012.  And at that time I re-discovered the same issue.  "Re-discovered"?  Yes, because I know that I had implemented it before in 2008, and the original time I wrote that code and discovered that issue was probably in 2004, in Visual Basic 6.  

So - this time I'm writing it down, because while there may be a helpful comment in the code (there will be for sure), my first instinct is always to search online.  And that search can lead me down many wrong paths, and wind up wasting a day or more.

Key words like:  JDE, F4311FSBeginDoc, "1456 Not in Original Mode of  Entry", xmlinterop, BSFN.

Primavera Gateway - Out of the Box

This was given at the Collaborate 16 conference Session ID: 10702 on April 12, 2016 at the

Mandalay Bay Convention Center, Las Vegas, NV

Abstract

Primavera Gateway is a recent product, released in 2014, designed to simplify integration between P6 and other systems.  But what exactly is it, and what do you get out of the box with Gateway?  In this presentation we discuss the history of Gateway, the architecture, how to use it, and the future of this product.

Primavera Integration History

The story of Primavera is the story of multiple software systems.  Joel Koppelman and Dick Faris started with Primavera with a product called Primavera Project Planner (P3) in 1983.  Over the lifetime of the company, Primavera purchased many other companies and products, and from the very first days it was a struggle to make them all work together and appear as a unified “Primavera” brand.    That struggle continues today, and in some ways is even more pronounced under Oracle.  But first let’s step back to discuss how systems can communicate.

In the 1980’s the idea of computers communicating with each other was not on many people’s radar.  Personal computers were new, and the internet basically non-existent.  In the 1990s we first got access to Application Programming Interfaces (APIs), which were entry points allowing software to communicate, but there were no clean standards and the variety of APIs proliferated with names such as CORBA, RPC, and COM Interop.  Some systems had APIs, most did not.   In the 2000’s the influence of the internet inspired APIs which worked over the fairly simple HTTP protocol.  Yet again, the specific ways of using that protocol varied wildly with different versions of the SOAP protocol, and various other XML-based API formats.  During this time companies such as Microsoft and IBM began producing integration platforms such as BizTalk, Tibco, and Tivoli.  Oracle too began its Fusion Middleware/SOA Suite family of products.

At Primavera, there was a Java API for P6 in the 1990s, and a COM-based API for Primavera Contract Management (PCM).  Once both systems went to web-based products in the 2000s, both began to get HTTP-based interfaces, which collectively are called “Web Services”.  These were ways of communicating with systems, but did not in and of themselves integrate any specific data.

Primavera used these APIs to develop integrations for their products.  They created TGIF for integrating Timberline Accounting with PCM, and also created Inspire for integrating SAP and P6 (Technically Bristlecone developed Inspire, but Primavera bought the product).

When Oracle acquired Primavera in 2008, they began trying to integrate Primavera with their own systems using the Fusion Suite of products.  But due to the complexity of that software, integration projects tended to be either so simple as to be unhelpful, or so complex to be single, large, one-off, projects for a specific company.

Rather than wait for Oracle to provide a solid solution, the Primavera General Business Unit (PGBU) decided to to create an integration platform themselves.  A key goal was to replace the myriad of integration technologies with one.  This is Gateway.

Gateway Goals

Gateway does not eschew Fusion/SOA Suite technology.  The ideas of web services, pluggable architecture, and independent communication layers is sound.  But Primavera consciously decided to not build a completely generic integration engine.  Instead, they built something that is focused on P6, and which allows the Primavera team to replace the hodgepodge of technologies with one solid, supportable product.

This technology, Gateway, was first used to replace the Inspire integration between SAP+P6. Once the SAP integration was complete, Primavera continued to roll out data providers for other systems with each new release.  From a support point of view, this is a big relief.  Rather than supporting many integration technologies, they can support one, which also gives them the ability to continue improving on the core product.

Here are some of  the goals of Gateway:

• One complete platform for integration
• Tie together strategic products with P6
• Provide a set of supported integrations out of the box
• Allow extensibility through customization

These goals drive the development of Gateway, and explain many of its features.

Out of the box providers

Data providers are pieces of software that allow programs to talk to other programs.  This sounds pretty confusing, right?  How about a diagram:

Here we have the P6 program itself.  P6 is a great product and  it does its own thing.  It is not a product for integrating data by itself.  Instead, it has an API which something like a P6 Provider can use to communicate with P6.  For example, the P6 Provider can tell P6 to give it a list of projects and activities.  The Provider can also ask P6 to add, update, and delete projects and activities.  Other programs can talk to the provider.  Such programs could be Excel, MS Access, or a custom Java program.  Really anything that can communicate over the Provider’s protocol and knows the proper syntax.

The Oracle Primavera team works to produce new providers for other products.  And very importantly, the team has provided a set of specifications which allow others to create their own adapters.  These teams may be within Oracle, but part of another division working on other products such as VCP or EBS.  They may be external companies writing providers for their own products, or they may be technology companies creating providers for yet more systems.  With the specification provided by Primavera, anyone in theory can write their own providers.

As of Gateway 16.1 the following Providers are available:

Primavera Providers

• P6
• Unifier
• Prime
• Instantis EnterpriseTrack

External Providers

• Value Chain Planning
• E-Business Suite
• SAP

• XML File

The Primavera providers are free to use if you are using them to exchange data among the core Primavera products. If you use the External providers, then you need to pay for the Gateway license.

There is a pattern here.  One the one hand there are providers for non-Primavera Oracle products such as VCP and EBS.  But there are also ties to Unifier, Prime, and EnterpriseTrack.  These last three are very important, because it helps to unify these products under the Primavera brand.  Now, rather than users wondering why their different Oracle Primavera products don’t talk to each other, the answer is that they do - using Gateway.

Providers and Deployments

A Provider becomes a Deployment when you give it specific information on how to communicate with its underlying system.  For example, you can set up one P6 Deployment for the Production system, and one for the Testing System.  So the same provider, but different immanentizations of it.

Gateway will synchronize data between deployments.  A key idea behind Gateway is that the systems involved do not have to reside in the same network.  If a provider can grant access to P6 in another environment, such as a hosted solution, then Gateway can still  integrate data.  In fact, none of the systems, not even Gateway, need to be in any specific location!

A Provider also contains a list of data objects it supports.  An example would be a Project in P6 or a Cost Breakdown Summary in Unifier.  The Provider says what properties on each object are available, and also says what Business flows its, and its objects can participate in.

Business Flows

Gateway has the concept of data Flows, and in keeping with the P6-oriented nature of the system, these Flows are of two types: Master Business Data and Project Data.  A Flow Type is basically a set of steps for integrating data.  

• Load Source Data
• Convert Source to Gateway
• Load Destination Data
• Convert Destination to Gateway
• Compare Gateway-mapped source and destination data
• Convert compared data to destination format
• Review Data
• Update Destination
• Save Feedback

These are very generic steps and do not do anything in and of themselves other than set up what happens in the actual Business Flow.

A Business Flow does the actual mapping.  It determines which Deployments are the source and target systems.  It determines the mapping from each of those systems into a middle-layer format called the Gateway layer.  You may have noticed that there is a provider called Gateway.  This is a special provider which defines the middle layer.  Data objects and their properties from Providers must map into this layer. This means that if you are mapping a system  which looks similar to P6, you’re in good shape.  But if you are mapping into a very different system, you may not be able to do what you need.

Below is an example of the out of the box business flows for Master data.

As you can see, there is a flow which maps EPS Codes from P6 to Prime.  Another one sends Resources to Prime.

More interesting flows are available at the Project level, as shown below.

Here we have functionality for sending Activities from P6 to Unifier or from Unifier to P6, for sending projects from one system to another, and sending cost information between systems.

Modifying Business Flows

You can modify Business Flows and create new ones in Gateway.  In order to understand how, let’s discuss Field Mappings.  These are stored in Gateway as mapping between two providers, two objects, and the fields to be mapped.  

Below is a screen for the mapping which takes Unifier Activity data and sends it into P6.  In this case we have three fields mapped:

The Unifier object called Activity Sheet maps to the P6 object called Activity.  The items in the white drop down boxes are not mapped, so please ignore them for now.  The three items below this are the actual mappings.  The Unifier field “uuu_P6ActivityId” maps to the Gateway field “Id” which then maps to the P6 field “Id”.    Likewise, the start and finish dates are also mapped.

What is shown above is called a “Direct” mapping.  Fields in each system map into another.  This is the simplest form of integration.

Groovy Mapping

The next out of the box mapping you can do uses a java-based programming language called Groovy.  An example of a mapping using this method is shown below.

Here is the business rule:  

The P6 Activity name should be updated from the corresponding Unifier activity, and should be the Unifier Activity Name in uppercase, plus a dash, followed by the Unifier Activity’s P6 WBS code in lowercase.  If the Unifier Activity Name starts with “Bob”, then append “‘s your uncle”.

So Unifier Activity named “Bobby” with WBS named “Motown” would translate into a P6 Activity named “BOBBY - motown’s your uncle”.  

To do this we select the two Name and WBS fields from Unifier and tell them to map into the Gateway Activity Name field.  This is the left side of the image.  

The “Validate Expression” button will tell you if you’ve written valid Groovy code. It can be a challenge to get all of those parentheses, semicolons and squiggly brackets exactly right, since this is simply a text box and not an IDE by any measure!

That is for the Unifier to Gateway mapping.  For the Gateway to P6 mapping, we choose the Gateway Name field as the source and the P6 Activity name field as the target.  This next script looks at the Gateway Activity name, and checks to see if is starts with “BOB”.  If so, then adds “‘s your uncle” to the end.

So there is the groovy customization.  As you can see, you don’t want to get too complicated with this mapping, and you are limited to the fields available on the specific objects present. Also, even though the mapping is from Unifier to P6, we have to have additional mappings to the Gateway layer.

Gateway Future

Here in early 2016, the future of Gateway is murky.  Oracle is well on track creating new providers for Gateway, which is a good sign.  They started with SAP as the initial concept in the first release.  The next releases had Unifier and VCP, two Oracle systems which naturally overlap P6.  The release of the EBS adapter in 15.2 marks Oracle’s first tie in with their own ERP system, and it is possible that JDE or PeopleSoft may not be far behind.  Recent releases of P6 and Unifier have screens for setting up communications with Gateway, so it is certainly a key part of those products.

However, there are also a few trends which bring into question Gateway’s future.  Oracle has many products across many divisions.. They create databases, they create programming platforms, and they have many many products either built in-house or acquired over the years. Each of those groups tends to create their own integration platform.  There is Oracle Fusion/SOA Suite, which is a suite of tools for integrating “any” system to any other.  It does not do anything itself, but rather is a platform.  Yet its its complexity often drives users away.  Another product along these lines is Oracle Cloud Integration Service.  This is a friendly-looking system designed to let users set up integrations from a simple interface.  It is unclear how Fusion, Gateway and OCIS will interact, but Gateway has the benefit that it has, right now, actual integrations supported by Oracle.  It is not just a tool for making integrations.

Outside of Oracle there are many other competing products.  Microsoft has BizTalk, Service Bus, and Azure services.  Dell has Boomi, which already has interfaces for many non-Oracle systems such as SAP, as well as Oracle systems such as EBS, though nothing in the Primavera realm.  And the software industry is always changing, so it’s hard to predict what new products may emerge over the next few years.

Another interesting aspect of Gateway’s future is the future of the Primavera products themselves.  For example, while a strength of Gateway is integrating P6 and Unifier, the existence of P6 and Unifier as stand-alone products is called into question by Primavera Prime, which may eventually replace for both, unified into one product. Some  functionalities of Oracle Risk Analysis is already in the process of being folded into Prime.

Yet those are just the Oracle Primavera products changing and evolving.  There is also the spectre of Oracle Fusion.  Note that this is the Fusion ERP system, not the Fusion/Soa Suite integration stack, though Fusion ERP relies heavily on those technologies. This project, many years in the making, was designed to take the best practices of the top three Oracle ERP systems: EBS, JDE, and PeopleSoft, and re-engineer them all into one new product built on a more modern architecture.  Oracle Fusion HCM is already replacing EBS in new sales, and the accounting modules (GL, AP, and AR) are not far behind.  Among the suites of this new system is Oracle Fusion Project Portfolio Management.  Will this product replace the entire Primavera suite?  

My guess is that maybe, except for P6.

P6 is the one Primavera product that is most unique and most likely to remain as it is.  It is specifically designed to plan and execute large-scale construction projects, with years of first-hand experience and best practices baked into the product.  This is why it’s so hard to get professional schedulers to use the web version - the desktop product gets the job done!  So my guess is that Primavera P6 will still exist in 5 years’ time.  As for the other products, the future is not clear.  There is a definite change in the software industry as systems become more lightweight, web and mobile capable, and user friendly.  And all things are moving to something that is called the cloud.  Rather than bury things under the work could, I would say that the future means software that you can access from anywhere, and which will not be harmed when your local PC dies or you drop your phone in the mud - call this cloud if you will.  And these new systems by definition must talk to each other.  The way that they communicate will change, but the idea that systems must communicate is not going to go away.

Note: The contents of this paper are the personal opinions and writings of Daniel Williams.  They do not represent the views or opinions of Oracle, OAUG, or Quest  in any way.

The Differences in Insurance Between Procore and Sage 300

Insurance is Crucial

As an individual, keeping your insurance policies up to date may not seem like a big deal.  For most of us, the biggest hassle is re-signing up for our existing health plan every year, and remembering to print out a new auto insurance card and put it in the glove box.

But if you're running a construction company, maintaining insurance is not so simple, yet it is critical to your bottom line.  As a general contractor, you are responsible for all of the subcontractors working for you on site.  So it's not just your policies which must be up to date, but everyone working for you must have current valid policies as well.

AP Controls Protect You

Fortunately, Sage 300 has built-in handling of insurance compliance.   If you try to pay a commitment which is out of compliance, you will be warned or outright prevented from doing so, depending on your AP vendor configuration.




This is fundamentally important.  You cannot have a subcontractor working on your job who does not have current insurance and proof thereof.   If, for example, they drive a truck into a ditch and they are not covered, you are financially responsible.  And that could make the difference between a profitable job and a loss.

If you're only using Sage to manage insurance, this is not a big deal. But many companies are now using Procore for project controls and management, entering commitments insurance information in that system, not directly in Sage.  So now there is a dilemma- which system should control insurance? And if you want accurate information in both, do you just double up your work?

Insurance in Procore

The key is to make sure that the insurance in both systems is up to date without needing to enter it twice.  But the two systems do not treat insurance identically.  Let's see what that means.

In Procore, insurance is managed at the Company level.  For the sake of simplicity we are going to refer to these Companies as Vendors, knowing that we mean "Companies which are used for Accounts Payable and which are linked to Sage AP Vendors". 

A Procore vendor has insurance policies.  You can create new policies at the global level, and you can also create insurance policies for specific projects.  For example, if you have a project in Turks and Caicos, and your US policy does not cover you.  Or, more practically, if you have projects in different states where policy requirements differ.





In Procore there are not many restrictions on Insurance policies.  You can have more than one policy with the exact same type.  And right now, commitment and payment approvals are not tied to insurance. But if you're using Procore, you are likely doing so because it is easy to use and get data into the system.  You've got people in the field updating things practically in real time, and these same people who are doing submittals, inspections, and drawings are likely also to be the ones with the latest insurance information.

Now let's see how Insurance is set up in Timbeline.

Insurance in Sage

The main difference in the structure of Insurance is that while in Procore you can enter as many insurance policies as you like, in Sage there are only six forms of insurance allowed:

• General Liability
• Automobile
• Umbrella
• Worker's
• Custom 1
• Custom 2

You can only use these six, but you can customize the last two (globally) to be whatever you want.  Each type has the following settings:

Now this is insurance for a specific vendor.  But you can also have insurance  specific for each Commitment in Sage.  This concept does not exist at all in Procore.   Isn't this odd - both systems have insurance at the Vendor level, but in Procore you can also set insurance for a particular vendor on a project, but in Sage you can put insurance on a commitment.

The data you put  on Commitment -level insurance is mostly the same as with vendor  insurance, as shown below.



But note these differences:
Vendors have "Require per commitment", which means that each commitment  for that vendor must have its own insurance policy set.  Vendors  have "Proof Required", and  Commitments have "Required", each of which means that the insurance policy must be set on the vendor or commitment and in effect in order to pay the vendor in AP.  The "Override" setting means allow a vendor  to be paid in AP, even if the insurance is not received.  You will still get a warning, though.
The "Received" on the commitment is an oddball.  It is a check box which effectively means  the same thing as the "Received Date" on the commitment and vendor.

Sage's insurance setup helps to enforce compliance.  When your records are up to date then you can be sure that you won't pay vendors unless they are in compliance.

Keeping them in Sync

So how best to keep the two systems in sync?  Well, first you need to make sure you understand what it  means to be in sync.  Both systems  have global vendor insurance.  But Procore lets you have an unlimited number of policies of  any type, while Sage only lets you have 6 policies, 4 of specific types, two you can customize.

So at the vendor level, you can sync up to 6 types of insurance between Sage and Procore.  But you need to decide on a convention for mapping the types.  For example, will your Sage "Worker's" insurance map to one in Procore called "Worker's"  or "Workers" or "Workers Comp", or some other variation of "Worker's Compensation Insurance"?  And what will you call the two custom insurances, if anything?

Once you've decided how to map the different types  for each vendor, then which fields will be mapped?  Some are obvious.  Sage "Company" maps to Procore "Insurance Provider", just as the Policy numbers easily map as do Limit, Effective Date, and Expiration Date.  There is no "Received Date" in Procore, but there is a "Received" check box, like the one on commitments in Sage.  But there is no check box for received for Sage vendor  insurance, just the received date.

In Sage there is "Required" and "Override", and  in Procore there is "Exempt".  Should "Exempt" be checked if "Required" is not checked?  Or should  it be set if "Override" is set?

Now those were the easy decisions!  Those were for when  you have the same vendor in both systems and you want to map insurance.  But how should you deal with project-level insurance in Procore, and commitment-level insurance in Sage?


In Procore, every commitment belongs to one and only one project.  But in Sage, a commitment  does not have to be associated with a project at all!

Procore commitments must always belong to a Projects.  But Sage commitments are associated with projects through their lines.

Insurance for Sage Commitments

Since commitments always have an AP Vendor, and since that vendor can specify whether insurance is required per vendor, the first thing to ensure is that if there is a vendor in Sage which has "Required per Commitment" checked, then each commitment must also have the same insurance as its parent  vendor.  But there is no analog in Procore.

Insurance for Procore Projects

In Procore, if you have project-level insurance for a vendor, that implies that in Sage, each commitment to that vendor within that project should have the same insurance.  This gets tricky because in Sage, a commitment is not tied to any  specific project directly.  Instead, a commitment has lines, and each line is tied to a project.  But there is no requirement that lines on a commitment must be to the same job.  You can write a subcontract or PO and have different lines tied to different jobs.  Sage does not care.

This Sage commitment has two lines written to two different projects, and one line written to none!

Let's assume the above scenario happens, and in Procore, Vendor 100 has a global auto policy, and a specific auto policy for jobs 03-001.  Which policy should be used for this commitment in Sage?  Well, there is no good answer, at least no answer that can be automated.  Many companies, however, have a policy that each commitment  must be tied to one and only one job.

Conclusion

It is possible to have insurance in both systems, and to have a limited set of insurance types in sync  between the two.  But there are going to be compromises.  Whether it is in which if the 6 types of global vendor insurance you decide to link, or how to process insurance at the project and commitment level, choices need to be made.  In the next post I will describe what I feel is a good compromise that would be helpful for most companies.

Xamarin at OpenWorld

On the first day of Oracle OpenWorld I was walking along 5th street, between Moscone West and Moscone South, when someone handed me a flyer. This is not unusual at OpenWorld, and I expected the flyer to be about some thing which I did not care about in the least, some obscure company that did some obscure thing with some obscure Oracle product.

But the flyer said Xamarin.  I did a double take.  "Why is Xamarin here?" I thought.  OpenWorld is dominated by Java and Java developers.  And Xamarin is all .NET.  Not just a shop that uses .NET by chance or casually - these guys are hard-core, serious developers, and the Mono/Xamarin team has been core to the development of .NET.   So why were they here in the land of Java? I pondered this a few days, then on Tuesday night, decided to stop by their event at the Red Dog saloon.

So why did this strike such a chord?  Well, I am a fan of walking, and a fan of podcasts.  So I tend to walk alot and listen to alot of podcasts.  Miguel de Icaza is a founder of Xamarin, and I recall quite well him talking about the founding of Xamarin back in 2011.  It could have been on a number of different podcasts, such as Hanselminutes, Herding Code, or even Ruby Rogues.

Before Xamarin, Miguel worked on Mono - a project started in the early 2000s to make .NET run on non-Windows platforms.  That project was exciting to me, and even though most of our clients are 100% windows shops, I followed the developments in Mono.  The fact is that Microsoft claimed that .NET would follow standards and be platform-neutral, but that was just a theory.  Miguel and his team had the audacity to take that theory and make it a reality.  They created Mono, a version of .NET that could run on non-Windows devices.  It was not easy by any means.  They worked with/struggled against Microsoft, both politically and technically.  And wound up making a success, and keeping Microsoft true to its claim of platform neutrality. But the Mono project was always overshadowed by the fact that the Mono team worked at Novell, a rickety old corporation, ready to die or fade like so many other pre-millennial companies that failed to stay lean and relevant.

Fortunately (in hindsight) Novell was acquired by another company in 2011, and laid off Miguel.  He then announced the foundation of Xamarin, a company dedicated to carrying forward on the Mono ideals.  This was a great underdog story, so really appealing to me and many others.  Xamarin launched Xamarin studio, a cross-platform integrated development environment (IDE) for .NET development.

Another Mono product which Xamarin further developed was Mono Touch and Mono for Android, frameworks for deploying .NET solutions onto iOS and Android devices.  I had heard about this, and recall a "smackdown" meetup back in 2012/13 where Xamarin was pitted against PhoneGap and Titanium in a contest to see who could build an app fastest.  This was fun and interesting.  But my group does not do app development, and so I did not really follow this further.  Xamarin faded from my awareness, into the background of a zillion other software companies.

So now it's 2015, a few years since Xamarin was founded, and here they were at OpenWorld.  It turns out they are headquartered in San Francisco (for some reason I imagined Miguel was in Colorado Springs).  And the company just joined on as a partner or Oracle (see the announcement here). And Xamarin now has a focus of which I was unaware.  They are dedicated to ensuring that using Xamarin, you can write apps which will work on ANY device.  Their team in Denmark purchases mobile devices from around the world and has an extensive suite of tests to verify that apps made from Xamarin work on them all.

I had a great conversation with Charles Wang, automation engineer, and Villars Gim, procurement manager.  They explained how Xamarin has three areas of focus:  Building, Testing, and Monitoring.
Building is ensuring that Xamarin Platform enables developers to write C# code for their mobile apps and those apps, written once, can be pushed onto iOS, Android and Windows phone.  Possibly more device platforms than that, but who really uses Blackberry anymore?

Testing is verifying that the apps created with Xamarin will work on almost all devices.  Developers can use Xamarin's TestCloud to run tests on practically any device.  And Villars is responsible for making sure that they actually have every device that they can lay their hands on - from the latest iPhone to the most obscure/obsolete phones and tablets.

Monitoring is fairly new. This is having an infrastructure for getting feedback from Xamarin apps running on devices in the hands of end-users. Checking stability and performance, and using this to identify issues quickly.

So I am very glad I went and learned more about Xamarin.  The underdog of 2011 is now a thriving company, with a strong team of very intelligent and enthusiastic people. And their very impressive suite of mobile development tools help you create, deploy, monitor your apps across devices.   Now I just wish I had a reason to make an app...

Good on ya Miguel!

San Francisco
Oct 2015

OpenWorld - SIG Sunday

While the official Oracle OpenWorld sessions start on a Monday, the Sunday prior is dedicated to user group sessions.  Usually people arrive on Sunday and the sessions are in the afternoon. But this year the Oracle Primavera SIG was at 9am - and that was not even the earliest session!

The sessions started at 8am and continued to 4:30. There were about 20 to 25 sessions going on at any given hour, for 8 hours.  That's a lot of people and a lot of info!   So what are all of these talks?

A SIG is a Special Interest Group, organized by OAUG, IOUG, and Quest.  There are many such groups, dedicated to many interests. There are ones about technology such as BI Piblisher and Fusion Middleware.  There are regional ones such as Latin America and Central States.  There are sector specific ones such as Higher Education and Cost Management. And of course application specific like Primavera.

The OPSIG meeting was run by John Hartman of CH2M Hill.  At that meeting I learned that P6 Analytics is being renamed to Primavera Analytics, in anticipation that future versions will provide analysis of more than just P6, such as Unifier and Instantis.  We also learned about the activities of the SIG, most importantly that the deadline for Collaborate 16 abstracts is less than two weeks away! 

After OPSIG I did not have anything specific planned, so attended a few of the talks on the roster.

The first one was about - Trek Bicycles!  A subject dear to me as I certainly wished I had been out riding my Trek on this lovely fall Sunday.    It was quite interesting, given by Bryan Turner of Trek, and Viral Doshi of KPIT.  Trek recently set up sensors at their plant in Wisconsin to track their supply of decals.  The decals go under the outer coating of clear paint on a bike, and are specially ordered from suppliers as needed.  If they don't have the decals, they can't finish their bikes - which is bad for the bottom line.  And since the decals and suppliers were known quantities, this was an excellent situation to try out using sensors to automatically re-order the decals when needed.  This system is simply a set of sensors which measure the height of the stacks of decals in inventory.  When inventory gets low, the sensor communicates to JD Edwards, which then generates and sends out a Purchase Order.  Pretty simple, but a great way to save time at Trek and ensure that they don't have to halt a bike shipment due to decal shortage.

It also turns out that Trek was involved in the B-Cycle project in Denver/Boulder!  Another project dear to my heart.

The next talk was from Jon Wakefield of Velocity, a consulting company based on North Carolina.  They are specialists in Peopleoft, Fusion HCM, and Taleo.  Taleo is yet another company acquired by Oracle, back in 2012.  It is a product for recruiting and managing talent.  But the goals of the project are something I am very familiar with - integrating data between different systems.  The project for Velocity actually involved more than just integration, it started with helping the client migrate from PeopleSoft to Fusion HCM, no small task by itself.  Once the migration was done, Velocity set up systems for extracting data and importing data using a combination of batch scripts, file transfers, and imports.   We also learned about the HCM Data Loader, and other technologies that help with migrating and integrating data with Fusion HCM.

The last session I attended was Integration in the Cloud, by S&P, a company based in Mexico City.   This also was a talk about integrating Taleo, but this time with PeopeSoft.  The speakers, Arturo Viveros and Rolando Carraso, are Oracle ACE's in the integration space, and heavily involved in the Latin American user community.  They also have a blog called SoaMythBusters, which discusses the happenings around Oracle's various integration technologies.  One of the most interesting things I learned about at this talk was the existence of Oracle Integration Cloud Service (ICS).  This is a hosted service which can be used to integrate your data between cloud-cloud systems, or a mix of cloud and on-premise systems.  This is a very important part of Oracle's overall strategy of not just selling licenses anymore, but of being a provider of cloud services.  If you look at their pricing these days, the cloud license costs are comparatively cheaper than their on-site licenses.  But traditionally, cloud-hosted solutions can be difficult to integrate.  I have much more to learn about ICS, and am looking forward to doing so during the rest of OpenWorld 2015.

San Francisco, CA
Oct 2015

.   

Heading out to Oracle OpenWorld 2015!

The aspens have turned gold, and the bright crisp days of autumn are upon us here in the Colorado Rockies.  This means it's time to head to San Francisco for Oracle OpenWorld!

This year we are excited to learn more about the Primavera Gateway integration product and the plans Oracle has for its development in 2016.  We have dived deep into Gateway in the 3rd quarter of 2015, and have created our own Calance PeopleSoft Provider.  We are now actively using it to integrate data between PeopleSoft and a set of custom business processes in Unifier.  In this work we have learned much about Gateway, and we have feedback to share with the Oracle team on what we perceive to be its strengths, as well as its shortcomings, with the aim of helping this product improve and deliver better and better solutions for Primavera users.

We are also curious to learn about plans for Unifier, particularly its mobile options. These days clients (and you, and me, and everyone we know) prefer to do many tasks on mobile devices such as phones and tablets.  If an application cannot work on one of these devices, that is a major disadvantage. Unifier is fortunately not hindered by Java applets like Primavera P6.  So in theory, a re-skinning with responsive design could get Unifier working natively on mobile.  But it may be that Oracle Primavera would instead create a true mobile app, much like the P6 Mobile app for iOS and Android (sorry Widows phones!).  Or the lightweight Team Member HTML5 app which works great on an iPad.  Neither of these P6 solutions have the power of the desktop web, which is itself much less powerful  than the P6 Professional desktop client.  But they are good moves in the struggle to liberate P6 from the PC.  Anyway, we are much looking forward to learn what mobile options Oracle is planning for Unifier.

Although it is hard to miss a week of this lovely weather, with the leaves falling and the chance of first snow, San Francisco is a great place as well.  AirBnB and Uber make is easy, cheap, and  fun to stay and get around the city, and the entertainment this year is Beck and Elton John - how could you go wrong with that?


Boulder, CO
Oct 2015

PS: Our new website is now  live - check it out here:
http://www.calanceus.com/development/oracle-integration/

Fall in the Rockies

Procore, and its Integration API, is simply awesome

Calance joined the Procore Beta program in the 3rd quarter of 2015.  We had a long-term client who was moving to Procore and they needed some integrations with Sage 300 CRE that Procore did not provide out of the box.  This client has been using our Dimension Integration Framework to integrate data between Oracle Primavera Contract Management 13 and Timberline  Accounting (aka Sage 300 CRE) since 2009.   They were in the process of migrating off of PCM and replacing it with Procore, and asked us to help out.   

While we were a tiny bit sad to see yet another customer move off of PCM, that little sadness was greatly offset by the excitement we felt once we started working with the Procore team and got the opportunity to see Procore in action. It not only has a clean, modern user interface, but it has an equally modern and well-documented API, making integrating with it actually pleasurable!

Let's get the obvious out of the way first - what are the benefits of Procore from customer's point of view?    Well, it lets you manage contracts, vendors, commitments, submittals, RFIs, bids, punch lists, and more.  All the things you need to manage construction projects, making it ideal for General Contractors.  You can even manage Prime Contracts, which is a very nice feature.  It is hosted, so you don't have to purchase hardware and go through painful installations (I'm looking at you Oracle!).  

Also, you can use it anywhere.  It's designed for modern web browsers, working great on PCs, Macs,  and tablets.  And while it's not ideal on a  phone, you actually  can zoom in pretty well and  still get things done.  Procore also provides free apps for mobile and tablets.  Right now these are mainly for reading information, but we expect Procore to improve on them with time.  

Procore provides a set of integrations with Timberline which provide basic functionality.  Where we get involved is where clients need solutions not provided by Procore, such as insurance updates and payment holds.  We are looking to take our complete Timberline integration suite we have developed over the years for PCM and adapt all of it for Procore. This includes projects, cost codes, extras, estimates, budgets, change orders, commitments, commitment change orders, payments, pay rates, and much more. It's a big project, but well worth it.

Another feature we love is demonstrated by the image below, a pop-up which appeared as we were working in the system one day:

As you can see,  the Procore team is constantly improving its product, and they are being very transparent about it.  As updates happen, everyone gets them, and are notified  in friendly messages like this.  They don't make a big deal of it, this consistent, continual improvement is key to their success. This mixture of technical drive and open communications makes Procore stand out as a product designed for the next generation of users.  And even old-timers like myself really appreciate it!

Boulder, CO
Oct 2015

PS: Our new website is now  live - check it out here:
http://www.calanceus.com/development/integration/