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?
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.
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.
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.
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.
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:
I simply find this approach inelegant and fragile. I don’t like using file triggers for flow control.
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!
@"Mark Hadler", your input was helpful, and I’m sure I’ll use these ideas elsewhere if not in this case. Thanks!
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:
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#
Personnally I run a JOBP:First step unloads elements marked for transport.to a .TXT fileLast 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
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.
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.