As a citizen integrator, I want to send and receive Concur data from within an integration flow.

syndesisio / syndesis

This project is archived. A flexible, customizable, open source platform that provides core integration capabilities as a service.

https://syndesis.io/

Apache License 2.0

598 stars 202 forks source link

As a citizen integrator, I want to send and receive Concur data from within an integration flow. #3003

Closed gaughan closed 5 years ago

gaughan commented 6 years ago

As a citizen integrator, I want to send and receive Concur data from within an integration flow.

DoD:

Concur connections should support two actions: -- Retrieve : used only in a start connection. This action should retrieve existing Concur records. -- Create : used in a step or finish connection. This action should be ….
The feature owner has confirmed one of the following: -- There is an initial draft of the user doc for this feature. -- The writer acknowledges receiving enough information from engineering to write the initial draft of the user doc for this feature.

EPIC: https://github.com/syndesisio/syndesis/issues/2632 Issues: https://github.com/syndesisio/syndesis/issues?utf8=%E2%9C%93&q=%3Dconcur+ Concur docs: https://developer.concur.com/api-reference/ Concur API versions https://docs.google.com/document/d/10fLUtRld49XXxG6Ya-sRcBGDh9dW91bmBmGcDhmxw78/

zregvart commented 6 years ago

REST APIs cannot be used at the start of the integration. Connections that appear at the start of the integration are limited to consumers, i.e. data is received by them asynchronously and independently (think message queue). One way to have the connector appear at the start is to support polling, as we do with SQL connector for example.

gaughan commented 6 years ago

Including polling like with gmail connector or SQL connector seems like the way to go. Also in the callouts API there is support for event notification, correct?

zregvart commented 6 years ago

I think we can add polling to Concur connector, not sure if we would like to enable it for all actions, perhaps just the idempotent ones (using GET HTTP verb).

I think there was an issue about doing this for all custom API connectors, can't find it now.

Callouts seem to be a way for Concur to issue requests to Syndesis, that would be somewhat similar to WebHook connector we have.

What we've done so far is to base the Concur connector on the custom API connector, so we took 30 Swagger specifications from Concur API explorer, combined them into one, generated the custom API connector, tweaked it a bit and then packaged it within Syndesis as a built in connector.

This makes it a producer-only connector (a client), to make it a consumer-producer connector (client-server) we might need to combine two connector bases into one (WebHook + API) or create a Concur Camel component to base the connector on.

Would be good to have some concrete use cases to drive the development.

KurtStam commented 6 years ago

So we implemented the v3.0 API in our Concur connector. For an overview see: https://developer.concur.com/api-explorer/

I think I should probably remove the APIs that are deprecated: Attendee, Attendee Types, PUT on Lists, Receipts (Are we forced to use v4 here?)
I'm not convinced we need to implement polling. I've been looking through the API and really see no resources we need to monitor for changes. Even most GET APIs require some sort of ID input. So I think we don't need to have it as a 'Start' connector.
The API is rather large, 85 endpoints. We should probably have a meeting with QE and Documentation on how to deal with that.
@gaughan specific user stories are also a must. Let me see if I can get inspired by what IT is doing to get this going.

kcbabo commented 6 years ago

On points 3 and 4, I don't believe we need specific user stories for all 85 endpoints. The point of the connector is to expose the set of API resources for Concur, which will change over time. The user story for Concur is basically consuming their API using the API client connector. If there are edge cases or constraints that need to be specifically addressed in the user story, please raise them so we can make sure the user story accounts for them.

gaughan commented 6 years ago

On point 1, removing all deprecated sounds good. I don't believe we are forced to use v4, (not being on v4 doesnt make it deprecated etc)

tplevko commented 6 years ago

@kcbabo ad.3: from QE POV, there exists a concern related to exposing all of the 85 endpoints. We don't really need scenarios for all 85 endpoints, but at least some prioritized subset, which should be tested and then cover this tested subset in our documentation. It would be also good to form the subset corresponding with the mostly required customer scenarios. I don't think QE has ATM resources to cover all available endpoints, and there can occur situations as described by @zregvart in https://github.com/syndesisio/syndesis/issues/3041

kcbabo commented 6 years ago

We have an internal user that has concrete requirements of Concur integration. I suggest we start with those and then add more as we go (i.e. in future releases).

@gaughan - can you work with @KurtStam to document the use cases of our internal stakeholders?

gaughan commented 6 years ago

Usecase is confirmed as the scenario previously described: list item api. There are two other use cases both blocked due to missing functionality so not likely to be implemented.

Update any user (blocked by missing manager update function)
Add project duration or end date. (missing)

stale[bot] commented 5 years ago

This issue has been automatically marked as stale because it has not had any activity since 90 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions!

stale[bot] commented 5 years ago

This issue has been automatically marked as stale because it has not had any activity since 90 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions!