Re: [Arsperl-users] Problems writing to join tables - no entry ID to return

[Thilo S. <thi...@ap...>]

This is a problem of the underlying C API, so it cannot be fixed in ARSperl.

That being said, I've encountered this situation too. Here's how I 
worked around it:

Create a filter on "Submit" on the join form containing a "Message" 
action of type "Note". The message text should contain information which 
allows to uniquely identify the newly created entry, e.g. a previously 
generyted GUID. The message content is returned in the $ars_errstr 
variable after the ars_CreateEntry call, which can be evaluated by your 
script.

If you absolutely need the Request-ID of the created entry, that's a bit 
trickier, but can be achieved the following way:
You might push the Request-IDs of the base entries (which are known at 
the time when "push fields" is executed) to some dummy form which exists 
only for this purpose. You can then output the base IDs via a message 
filter action on the dummy form.


Regards,
Thilo



Tim Skirvin wrote:
>         A short summary: I'm having problems with ARS::ars_CreateEntry ()
> returning a useful return value when it is creating an entry in a join
> form/table.  This appears to be a systemic problem, and I'm not really
> sure what to do about it.  I'm curious if anybody else has found a
> solution to this.
>         
>         Some background: I'm our current resident ARSperl developer at
> Stanford.  We use Remedy to handle our Incident Management and other
> related areas, and we're starting to build a CMDB based on the same
> infrastructure.  I've built up the general interface to handle all of
> this, based on (at the lowest level) the ARSperl interface.
> 
>         I'm currently working on the engine to populate the BMC CMDB
> product based on spec CMDBf data (this is XML, for those that don't know).
> The CMDB is based very heavily on join tables; pretty much *everything*
> you write to is a join table of some sort or another, and there's no
> real way to work around this.  
> 
>         However, our testing has found a major problem with this: it is
> impossible through the API to write directly to a join table.  Instead,
> when information is offered to the join table (via ars_CreateEntry ()),
> underlying work-flow creates the appropriate entries *indirectly*.  This
> generally works - that is, the entries are created appropriately, both in our test
> forms and in the default BMC_CMDB forms.  But the correct value is not
> returned, according to the API docs:
> 
>         http://www.arsperl.org/manual/ars_CreateEntry.html
> 
>         On success, we're supposed to get a request ID.  On failure, we
> get undef.  In this case, we get a *blank* request ID.  All we can really
> say about this is that we can tell the difference between a failure and a
> success (though in this case, it leaves us in a situation of "we know we
> wrote, but we don't know *where* we wrote", which I would argue subverts
> the API pretty badly).
> 
>         So - what to do about it?  I've started writing up some wrapper
> code in my own libraries that, if we get a blank return code, goes out and
> tries to find the entry again based on the data offered during the create
> (dying if 0 or 2+ entries are found); but this doesn't seem like the right
> general solution.  This seems like something that the ARSperl libraries
> should take care of on its own, though I have to admit that I don't really
> know how it *would* do so.
> 
>         Advice, thoughts, and code examples are welcome.  I'm more than
> happy to elaborate as well.
> 
>                             - Tim Skirvin (tsk...@st...)
> 
> 
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------------
> 
> 
> ------------------------------------------------------------------------
> 
> 
> 
> --
> Arsperl-users mailing list
> Ars...@ar...
> https://lists.sourceforge.net/lists/listinfo/arsperl-users