Hi Luis,

There is no general way to do that right now; it would have to be something
each repository connector supplies individually.  I've now set up a
mechanism for doing that, though.  Please have a chat with Piergiorgio if
you want to learn more.

Thanks!
Karl


On Wed, Sep 27, 2017 at 4:57 PM, Luis Cabaceira <[email protected]> wrote:

> I was referring to get job input data, to access the job settings you
> configure for the repository input connectors. For example repository paths.
>
> [image: Inline images 1]
>
>
>
> On 27 September 2017 at 18:06, Karl Wright <[email protected]> wrote:
>
>> As discussed offline, this is what Piergiorgio and I agreed would work:
>>
>> (1) There will be a new, explicit, RepositoryDocument field that is meant
>> to contain the document's source path.
>> (2) The RepositoryDocument URL field will continue to be used as an ID for
>> updating or removing documents in the target repository.  This will mean
>> that output connectors written on top of repositories will need to expect
>> the repositories to have a document field already created to store this
>> attribute into.  For now this is OK even though some CMIS repositories
>> don't have this capability.  Output connectors will need to locate
>> documents when given the URL by searching for the document with that
>> attribute value in the specified attribute.
>> (3) If other bits of information need to be communicated from Repository
>> Connection to Output Connection, we'll add explicit fields in the
>> RepositoryDocument for those too.
>>
>> I've committed the changes needed to Piergiorgio's branch.
>>
>> Karl
>>
>>
>>
>> On Wed, Sep 27, 2017 at 6:24 AM, Karl Wright <[email protected]> wrote:
>>
>> > Hi all,
>> > Right now, the repository connector generates an "ID" for each document
>> > that is in the form of a URL, and heretofore we require the target
>> > repository to be able to keep track of that "ID" for each document, and
>> to
>> > request document updates and deletions based on that "ID".  But this
>> > doesn't work for some output connectors.
>> >
>> > What I'd like to understand is: why not?  What kind of IDs does an
>> output
>> > repository generally require to be able to update or delete documents?
>> >
>> > Thanks,
>> > Karl
>> >
>> >
>> > On Wed, Sep 27, 2017 at 6:12 AM, Piergiorgio Lucidi <
>> > [email protected]> wrote:
>> >
>> >> Hi Luis,
>> >>
>> >> it seems that here we have to work on the Content Migration extension
>> for
>> >> also the File System Repository Connector.
>> >>
>> >> This is exactly the same problem that I had during the development of
>> the
>> >> CMIS Output Connector for implementing the removeDocument method.
>> >>
>> >> I think that we should plan an improvement activity for this connector.
>> >>
>> >> Cheers,
>> >> PJ
>> >>
>> >>
>> >>
>> >> 2017-09-27 11:59 GMT+02:00 Luis Cabaceira <[email protected]>:
>> >>
>> >> > Hi all,
>> >> >
>> >> > I'm writing the BFSI output connector and i would like it to support
>> all
>> >> > existing input connectors. I've tested it with cmis input where i can
>> >> > obtain all the information i need via the getFields method of the
>> >> document
>> >> > object.
>> >> >
>> >> > Now if i use the filesystem input connector, all i have in getFields
>> is
>> >> the
>> >> > URI of the document. I need to access the Job data to know the input
>> >> > connector repository root paths and i'm not finding a way to get it.
>> >> >
>> >> > Is there a way, in the output connector to access the Job attributes
>> ?
>> >> >
>> >> > Cheers,
>> >> > Luis Cabaceira
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Piergiorgio Lucidi
>> >> Open Source Evangelist and Enterprise Information Management Specialist
>> >> Mentor / PMC Member / Committer @ Apache Software Foundation
>> >> Community Star / Wiki Gardener / Global Forum Moderator @ Alfresco
>> >> Author and Technical Reviewer @ Packt Publishing
>> >> Technical Advisory Group Member @ Microsoft
>> >> Top Community Contributor @ Crafter
>> >> Project Leader / Committer @ JBoss
>> >> http://www.open4dev.com
>> >>
>> >
>> >
>>
>
>
>
> --
> Luis Cabaceira
>

Reply via email to