And I will add this to the concept... A "submit" to a Join form (or any other form) might actually create multiple children that might be expressed through a one to many relationship.
Take for example a simple definition of a support person. They might have multiple phone numbers. However for "ease of data entry" there might be multiple 'Phone number' fields that allow the user to "submit" one record and have workflow actually splinter each of those fields into child records of the primary parent record that is created from the "submit". (And other workflow could present the multiple records back as part of the parent for reporting reasons too. (With or without the need for a join form.) My Bottom line... the simple "Submit" construct/idea that it would always end in one record being created is a bit flat for "more advanced application/UI logic", and it is the responsibility of the developer to accommodate such things in their application design/implementation. As a possible "solution" your filters could do the push actions in a non-phased filter. Then do a Application-Release-Pending (Run Process) action followed by a SetField action to get the Entry ID (field 1) value for the child that was just created to pull the value back into the current transaction. But here is where the "API" is really lacking (in some peoples minds) in so far as the ARS developer has no direct control over what gets stuffed into the returned EntryID from the API. (That is "hard coded" as a function of the ARS server as far as I can tell.) So, the developer could opt to use a message action to send back a list of messages that would provide the user/client API program the information that was returned along with the Form or Schema that the EntryID value relates too. Obviously there are several option there to. The workflow could create "submit results" records that are also created by the workflow on "Submit" that would let the Client API search that form for the results too. (Again, the single submit might create multiple records being presented back via the same join.) So all in all, I doubt Remedy (or BMC) would consider the described behaviour a bug. Rather it is a designed behaviour. I get the impression that knowledge that the current design is not the "most general case" is known and was deemed "ok" long ago. Such decision may/likely limit the "core use case"s that are possible for ARS applications. (or force other design patterns to be used.) Maybe it is time an enhancement was submitted that would help them(BMC) to make their implementation more generalized? ( Like to allow a developer some control over the Entry ID that is returned from an API call?) Just some food for thought. HTH. -- Carey Matthew Black Remedy Skilled Professional (RSP) ARS = Action Request System(Remedy) Love, then teach Solution = People + Process + Tools Fast, Accurate, Cheap.... Pick two. On 10/25/06, Papolu, Appajee <[EMAIL PROTECTED]> wrote:
Curtis, Your observation is correct, almost. The create entry operation can be sent from API clients even for Join/display-only forms. Then it is up to server (or, in fact the workflow tied to the forms in question) to do whatever is necessary. Typically join forms that are part of a reasonable app do have necessary workflow performing necessary 'pushing data' to base forms. Thus for end-user (interactive user or a client program) - they would be able to successfully perform entry submissions. Only catch is that -- the system does not give out an entry id in such cases since one is not created by it directly as in regular form's case (instead join entry got created via workflow). So the workflow author may take additional steps to include some kind of INFO message or some thing that includes hints about the just created entry (i.e. a primary form entry id and secondary form entry id together). I am not too sure how easy such a thing could be considering multi-level joins etc and also app author may not consider this as a core use case as part of their app. Another workaround for an API client program is to follow up the create operation with a query with appropriate qualification identifying the just created entry. Regards Appajee -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Curtis Gallant Sent: Wednesday, October 25, 2006 6:50 AM To: arslist@ARSLIST.ORG Subject: Re: Java AR API weirdness Not sure if the same applies for the Java API, but for the C API according to documentation, you can't createEntry to a Join, you should createEntry to the base forms that make up the Join. I might be way off but I hope this helps Cheers, -------- Curtis Gallant -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of John Baker Sent: Wednesday, October 25, 2006 9:34 AM To: arslist@ARSLIST.ORG Subject: Java AR API weirdness Hello, Consider the following: EntryFactory entryMan = EntryFactory.getFactory(); Entry entry = (Entry)entryMan.newInstance(); entry.setContext(serverUser); entry.setEntryItems(items); entry.setSchemaID(new NameID(schema)); entry.create(); System.out.println(entry.getEntryID().toString()); Should create a new Entry and output the EntryID. This works fine, unless the entry was created in a Join Form, in which case an empty string (not null) is output. I've tested with the v7.0 API (patch 1 & 2). Has anyone else seen this behaviour? Is it really a bug or just incorrect use of the API? John Java System Solutions : http://www.javasystemsolutions.com
_______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
