EMERALDCUBE BLOG

Outbound Interoperability and R00460 – Playing Detective


Welcome back, Friends of the Cube!  Those of you that have been reading our blog since the beginning may remember a post back in 2014 by my CNC counterpart (and best buddy) Chris Bullock, entitled “Subsystem Jobs in a Wait State”.  Chris had discovered a buildup of subsystem jobs in a customer’s F986113 table, and they were all mysteriously related to R00460 – the Interoperability Generic Outbound Subsystem UBE.  I’ll pause here so you can read or re-read Chris’ blog post.  Go ahead, it’s not too long and it will provide a good foundation for the rest of this blog entry.

Okay, now that you’re back, you know that the R00460 is called whenever outbound interoperability is enabled in a JDE application.  Its job is to write the outbound records to the Z file tables, for interface with a third party system or sometimes, just for an audit trail.  However, vanilla JDE versions are often shipped with the outbound interoperability enabled by default.  If you use ZJDE versions instead of creating your own, or if you copy ZJDE versions, those versions are calling for interop without you intending to.  It’s not really hurting anything, just quietly kicking off the R00460 in the background every time you use one of the applications in which outbound interoperability is enabled.

Over time, though, this can result in that buildup of records in F986113 that Chris came across.  Or, it can cause more serious problems.  Once, a client opened a ticket; they were receiving intermittent Web Client Exception error when vouchering in AP.  The issue did not appear to be related to a specific vendor, or a user timeout, or anything else that we could immediately see.  Chris and I noticed a Primary Key error on the Call Object Kernel logs – “Cannot insert duplicate key in object PRODDTA.F0413Z1”.  Aha – a clue!  The outbound interoperability was enabled in P0400297, and had been quietly writing outbound records for years and years.  Eventually, we were running up against duplicate keys in the Z file due to this process running unchecked for so long.  We turned off the interoperability, cleared the Z file, and the problem was solved.

So, how can you check 1) whether you are impacted by default outbound interoperability settings and 2) which ones they are?  As Chris noted last time, check your F986113 to look for R00460 buildup.  If you have that, then you have the disease – now on to the cure.  Review the processing options on the applications listed below.  Pay special attention to ZJDE versions as these are the most frequent culprits, but custom versions that were copied from ZJDEs may have the same setup.  This may take some time, to go through all versions of an application.  PRO TIP – you can run R98306 over each application on the list, and search the resulting PDF to check the settings for each version.  Note the ones you need to adjust.  Before you actually make the changes, you may want to check internally to be sure that these processes are not truly being used for an interface or audit purposes.  Once you have the all clear, it’s time to make the processing option changes.

The list below can be found in Oracle Doc ID 859763.1:

Checklist – Deactivating Outbound Interoperability

Check F986113 for R00460 job buildup
Run R98306 over all versions for the applications listed below (or manually review)
Note the applications/versions with the outbound interoperability enabled
Check internally to ensure this is not intentional or in use by an interface or audit process
Remove the interoperability processing option values by:

a. Fathpath to IV, call up the version, clear the processing option, click OK.  Repeat in each environment.
b.Alternately, if you are certain that the processing options for each version match across DV/PY/PD, then you can make your changes in DV and promote them.  Just be careful – you don’t want to promote someone’s test processing options to PD!

So, there you have it – a blueprint to track down and disable those outbound interoperability options.  Although they may not be causing issues today, problems could crop up down the road, so it’s best practice to turn off the functionality if you aren’t using it.  If you decide to use Outbound Interoperability in the future, or just want more information, check out Doc IDs 1275030.1, 1467270.1, and 1334253.1 on My Oracle Support.