Program to import UC4 objects from XML

[Michael A. Lowry]

I have a UC4 job that exports UC4 objects using the EXPORT script command. I would like to import the XML file into a different UC4 system. However, the process that triggers the import is not run from a UC4 job, so I cannot rely on the corresponding IMPORT script command.

Is there a command-line program to trigger import of an XML file — similar to ucybdbld, but for XML files as opposed to transport case files?

Alternatively, has anyone written a program to import XML files into UC4 using the Java API?

[Anon Anon]

Would is be possible to use an Event on the target system to trigger a IMPORT function for your scenario?  

We have a process that performs the EXPORT from one Client/System and sends the XML file to the target System.  On that System, there is a File Event running that detects the arrival of the file and activates the associated Script object to IMPORT the objects.  Maybe some version of this would satisfy your requirement.

 

[Michael A. Lowry]

That’s a clever idea, Mark. The main problem with that approach is that there’s no straightforward way to return an exit status to the initiating process. It cannot be fire–and–forget.

[Anon Anon]

If you mean by the "initiating process" that which performed the EXPORT, couldn't it also wait on a File Event? Once the IMPORT Script object has completed, it could send some type of status file back to the originating system where the waiting Event could then process it and exit appropriately.  That is what our process does since, once the IMPORT has completed, the EXPORT has additional processing to perform.

[Michael A. Lowry]

I thought about that too, and I don’t think it would work in this case. 

The export and import operations are independent, and often separated in time by weeks or months.

[Anon Anon]

Well, how about still using the Events, but don't actually perform the IMPORT.  Just use the Event on the receiving side to, for example, build a list of the received XML files in a Variable object and to notify the sending side of the successful receipt so it can end.  Then, whenever needed, perform the IMPORT using the previously stored XML files using the keywords/values in the Variable to drive the "delayed" imports.  That would at least decouple the two sides of the process.

[Michael A. Lowry]

The system that triggers the import is not UC4. It’s another completely different application called SCM.

SCM sits between the source and target UC4 systems, and stores the XML file. It’s related to configuration management and change management. The jobs initiated by SCM (again,not UC4 jobs) can run just about anything, but they still rely on traditional return codes to distinguish success from failure.

I could write a script to do periodic checks for the appearance of a file though, so yes, I could imagine something like this:

• The script triggered by the SCM job writes the XML file that is picked up by an EVNT in UC4.
• UC4 imports the XML file and writes a trigger file indicating success or failure.
• The SCM script waits some amount of time, and then checks periodically for the appearance of the trigger file from UC4.

I simply find this approach inelegant and fragile. I don’t like using file triggers for flow control.

[Anon Anon]

While you mentioned a Java API in your OP, there is at least under V8 the various flavors of CallAPI.  Is the UCXB???C utility used for the CallAPI for V8 the same one that you are referring to as the Java API?

A long time ago we built one (since abandoned) to use for OS/390.  It was pretty easy since the UC4 Script function could just be coded into the JCL and submitted.  Perhaps, depending on your platform, there is something there that you could use. 

Sorry I couldn't be of more help.  Good luck!

[Michael A. Lowry]

@"Mark Hadler", your input was helpful, and I’m sure I’ll use these ideas elsewhere if not in this case. Thanks!

[Michael A. Lowry]

We disallow use of the CallAPI in our environment, so the Java Application Interface is probably my best bet. Specifically, the ImportObject subclass of the XMLRequest class looks like what I need. I’m just not much of a Java programmer, so I was looking for alternatives.:smile: 

[Anon Anon]

How about using the CallAPI?

I use the CallAPI to set my new clients to 'GO' after creation.

Here's my script:

:set &ret#=toggle_system_status(GO)
: p &ret#

I pass the Client # when I run the CallAPI, for example:

UCXBXXXC SCRIPT=C:\automic\CALLAPI\start_client.txt LOGON=&client#,JENN,PM,<password> INI=C:\automic\callapi\ucxbxxxc.ini

The CallAPI logs into the Client with the User and then runs the script defined in my file.

[Michael A. Lowry]

Jennifer_Jinhong_34 wrote:

How about using the CallAPI?

Thanks, Jennifer. I am sure that your idea would work. However, we have decided not to allow the CallAPI, so I must find an alternative approach.

[MichelNicolas608079]

Personnally I run a JOBP:
First step unloads elements marked for transport.to a .TXT file
Last step submits a call api within a different UC4. The API job imports all the elements via the load utility.
You could change the API using a EVENT.FILE within your target environment. Check the last modification of the export file and use it to trigger your Load/import.
Best regards.
Michel

[Michael A. Lowry]

Michel, thanks for the reply.

We use the transport case method (ucybdbun,ucybchng, anducybdbld) for the majority of objects. However, we cannot use it in this case, for a simple reason: we need to be able to change VARA object values in the exported file before it is imported into the target UC4 system. The UC4 DB change programucybchngis not able to change VARA object values. (I have submitted a product enhancement request asking for just that capability, but I do not know the status of this request.)

And again, Call API is unfortunately not an option because we have specifically disallowed it.

[Anon Anon]

we use the &$SYSTEM# variable as part of keys that need to change values between systems. I also have a set of tools that create XML manifest files that are then read to move the listed objects into the TRANSPORT case so that the unload utility can be used to create the file. I have then used NSIS (NullSoft Installable Script system) to create an exe installer that calls the DB.load utility after prompting the user for a system and client to use for the load.

Happy to share if anyone is interested.

Chuck