[Architecture] ESB Connector for Nimble
Hi All, I have planned to develop the $subject.Please find the project plan below. Introduction Nimble is a social relationship management tool that brings together your contacts from many disparate locations into one place; gives you a dynamic, 360º view of each contact; and helps you nurture the new and important contacts in your network. Nimple API Operations CONTACTS API Basic Contacts API List contact - List contacts - List contacts ids Search contacts - Search contacts - Saved search contacts - create Saved search contacts - update Saved search contacts - delete Saved search contacts Create contacts - create contacts Get contacts - Get contacts details Update contacts - Update contacts Delete contacts - Simple contact delete - Advanced contact delete Contacts Notes API Show single note - Get single note List note - Get contact note list create note - Create contact note Update note - Update contact note Delete note - delete single note Contacts METADATA API Retrieve all meta data - List all contacts meta data (groups and fields) Create field - Create field Update field - Update field Delete field - Delete field Create group - Create field group Update group - Update field group Delete group - Delete field group ACTIVITIES API Task API - Create task Authentication Supports OAuth 2.0 protocol -- *S.Elilmatha* Associate Software Engineer, WSO2 Inc.; http://wso2.com lean.enterprise.middleware Mobile 0779842221. ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] ESB Connector for ZOHO Invoice
Ashalya, there are a lot of methods here which may not be doable in 3 weeks. Pls identify the main use cases around this app and build methods related to those. On Mon, Nov 24, 2014 at 1:04 PM, Sriashalya Srivathsan asha...@wso2.com wrote: I have planned to develop the $subject.Please find the project plan below. *Introduction* Zoho Invoice API gives the programmatic access to the Zoho Invoice service, allows to expand and build on the Zoho Invoice platform for small businesses across the globe[1]. *API Operations* *Contacts* -List contacts -Get contact -Create a contact -Update a contact -Delete a contact -Mark as active -Mark as inactive -Enable payment reminders -Disable payment reminders -Email statement -Get statement mail content -Email contact -List comments -List refunds *Estimates* -List estimates -Get an estimate -Create an estimate -Update an estimate -Delete an estimate -Mark an estimate as sent -Mark an estimate as accepted -Mark an estimate as declined -Email an estimate -Email an estimate -Get estimate email content -Bulk export estimates -Bulk print estimates -Update billing address -Update shipping address -List estimate template -Update estimate template *Invoices* -List invoices -Get an invoice -Create an invoice -Update an invoice -Delete an invoice -Mark an invoice as sent -Void an invoice -Mark as draft -Email an invoice -Email invoices -Get invoice email content -Remind customer -Bulk invoice reminder -Get payment reminder mail content -Bulk export invoices -Bulk print invoices -Disable payment reminder -Enable payment reminder -Write off invoice -Cancel write off -Update billing address -Update shipping address -List invoice templates -Update invoice template *Payment and credit* -List invoice payments -List credits applied -Apply credits -Delete a payment -Delete applied credit *Attachment* -Get an invoice attachment -Add attachment to an invoice -Update attachment preference -Delete an attachment -Delete the expense receipt *Recurring Invoices* -List recurring invoices -Get a recurring invoice -Create a recurring invoice -Update a recurring invoice -Delete a recurring invoice -Stop a recurring invoice -Resume a recurring invoice -Update recurring invoice template -List recurring invoice history *Credit Notes* -List credit notes -Get credit note -Create a credit note -Update credit note -Delete credit note -Convert to open -Void credit note -Email credit note -Email history -Get email content -Update billing address -Update shipping address -List credit note template -Update credit note template *Apply to invoice* -List invoices credited -Credit to an invoice -Delete invoices credited *Refunds* -List credit note refunds -List refunds of a credit note -Get credit note refund -Refund credit note -Update credit note refund -Delete credit note refund Customer Payments -List customer payments -Get a customer payment -Create a customer payment -Update a customer payment -Delete a customer payment Expenses -List expenses -Get an expense -Create an expense -Update an expense -Delete an expense -List expense comments history *Receipt* -Get an expense receipt -Add receipt to an expense -Delete a receipt *Authentication* Supports authtoken [1]https://www.zoho.com/invoice/api/v3 -- Shevan Goonetilleke Director of Engineering WSO2, Inc. lean.enterprise.middleware m: +94777340680 w: http://wso2.com ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] ESB Connector for Nest API
Shakila, if you need to use a third party library for this pls follow the the following tread (from Isabelle) to get it approved: subject - Must-follow process to bring 3rd party libraries into the WSO2 platform On Mon, Nov 24, 2014 at 12:56 PM, Shakila Sivagnanarajah shak...@wso2.com wrote: I will send the milestone plan by today On Mon, Nov 24, 2014 at 12:52 PM, Samisa Abeysinghe sam...@wso2.com wrote: What is the milestone plan? Thanks, Samisa... Samisa Abeysinghe Vice President Delivery WSO2 Inc. http://wso2.com On Mon, Nov 24, 2014 at 12:48 PM, Shakila Sivagnanarajah shak...@wso2.com wrote: Hi All, I (shak...@wso2.com) have planned to develop $subject. Please find the project plan here, *Introduction: * Nest API is a real-time data API (connect people with devices in their homes), offering subscription based access to data shared by Nest-devices. The Nest clients (created to access Nest device data) will use Firebase. Firebase provides a real time data synchronization service. *Operations:* Nest Learning Thermostat - View current temperature - View or set target temperature - Set fan timer - View or set temperature mode - View humidity - View online status and last connection information Nest Protect Smoke + CO Alarm - View CO or smoke status - View battery health state - View last manual test status and timestamp for last manual test - View online status and last connection information Home - View a list of devices in the home - View energy event status (Rush Hour Rewards) - View or set Away state - View postal or zip code - Set ETA *Authentication:* OAuth 2.0 (authorization) *API Summary:* Nest API v1.1 *Documentation URL:* https://developer.nest.com/documentation -- Shakila Sivagnanarajah Associate Software Engineer Mobile :+94 (0) 770 760240 shak...@wso2.com -- Shakila Sivagnanarajah Associate Software Engineer Mobile :+94 (0) 770 760240 shak...@wso2.com -- Shevan Goonetilleke Director of Engineering WSO2, Inc. lean.enterprise.middleware m: +94777340680 w: http://wso2.com ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] ESB Connector for ZOHO Invoice
ok ,noted,I'll consider the main methods only,Thank you. On Mon, Nov 24, 2014 at 1:43 PM, Shevan Goonetilleke she...@wso2.com wrote: Ashalya, there are a lot of methods here which may not be doable in 3 weeks. Pls identify the main use cases around this app and build methods related to those. On Mon, Nov 24, 2014 at 1:04 PM, Sriashalya Srivathsan asha...@wso2.com wrote: I have planned to develop the $subject.Please find the project plan below. *Introduction* Zoho Invoice API gives the programmatic access to the Zoho Invoice service, allows to expand and build on the Zoho Invoice platform for small businesses across the globe[1]. *API Operations* *Contacts* -List contacts -Get contact -Create a contact -Update a contact -Delete a contact -Mark as active -Mark as inactive -Enable payment reminders -Disable payment reminders -Email statement -Get statement mail content -Email contact -List comments -List refunds *Estimates* -List estimates -Get an estimate -Create an estimate -Update an estimate -Delete an estimate -Mark an estimate as sent -Mark an estimate as accepted -Mark an estimate as declined -Email an estimate -Email an estimate -Get estimate email content -Bulk export estimates -Bulk print estimates -Update billing address -Update shipping address -List estimate template -Update estimate template *Invoices* -List invoices -Get an invoice -Create an invoice -Update an invoice -Delete an invoice -Mark an invoice as sent -Void an invoice -Mark as draft -Email an invoice -Email invoices -Get invoice email content -Remind customer -Bulk invoice reminder -Get payment reminder mail content -Bulk export invoices -Bulk print invoices -Disable payment reminder -Enable payment reminder -Write off invoice -Cancel write off -Update billing address -Update shipping address -List invoice templates -Update invoice template *Payment and credit* -List invoice payments -List credits applied -Apply credits -Delete a payment -Delete applied credit *Attachment* -Get an invoice attachment -Add attachment to an invoice -Update attachment preference -Delete an attachment -Delete the expense receipt *Recurring Invoices* -List recurring invoices -Get a recurring invoice -Create a recurring invoice -Update a recurring invoice -Delete a recurring invoice -Stop a recurring invoice -Resume a recurring invoice -Update recurring invoice template -List recurring invoice history *Credit Notes* -List credit notes -Get credit note -Create a credit note -Update credit note -Delete credit note -Convert to open -Void credit note -Email credit note -Email history -Get email content -Update billing address -Update shipping address -List credit note template -Update credit note template *Apply to invoice* -List invoices credited -Credit to an invoice -Delete invoices credited *Refunds* -List credit note refunds -List refunds of a credit note -Get credit note refund -Refund credit note -Update credit note refund -Delete credit note refund Customer Payments -List customer payments -Get a customer payment -Create a customer payment -Update a customer payment -Delete a customer payment Expenses -List expenses -Get an expense -Create an expense -Update an expense -Delete an expense -List expense comments history *Receipt* -Get an expense receipt -Add receipt to an expense -Delete a receipt *Authentication* Supports authtoken [1]https://www.zoho.com/invoice/api/v3 -- Shevan Goonetilleke Director of Engineering WSO2, Inc. lean.enterprise.middleware m: +94777340680 w: http://wso2.com ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Stripe Web Connector for WSO2 ESB
Ok noted. I will create the milestone plan accordingly. On Mon, Nov 24, 2014 at 1:52 PM, Shevan Goonetilleke she...@wso2.com wrote: Keerthika, there are a lot of methods here too...pls define the some useful scenarios around this and implement only those methods (given that you have only 3 weeks to complete). On Mon, Nov 24, 2014 at 12:54 PM, Keerthika Mahendralingam keerth...@wso2.com wrote: I will share the milestone plan by today evening. On Mon, Nov 24, 2014 at 12:53 PM, Samisa Abeysinghe sam...@wso2.com wrote: Milestone plan for this? Thanks, Samisa... Samisa Abeysinghe Vice President Delivery WSO2 Inc. http://wso2.com On Mon, Nov 24, 2014 at 12:49 PM, Keerthika Mahendralingam keerth...@wso2.com wrote: Hi all, I have planned to develop $subject as described below. *Introduction* Stripe provides simple RESTful HTTP interfaces to handle payments. *Stripe API Methods* 1. Cards: Creates a new card for a customer. Retrieves an existing card details stored on a customer. Updates a card details. Deletes a card. Lists all cards belonging to a customer. 2. Tokens: Creates a card token that wraps the details of a credit card. Creates a bank account token that wraps the details of a bank account. Retrieves an existing token. 3. Customers: Creates a new customer. Retrieves the details of an existing customer. Updates the specified customer. Permanently deletes a customer. Returns a list of all customers. 4. Charges: Creates a new charge. Retrieves the details of an existing charge. Updates the specified charge. Captures the payment of an existing charge. returns a list of all charges. 5. Refunds: Creates a new refund for a charge. Retrieves details about an existing refund. Updates the specified refund. Returns a list all refunds belonging to a specific charge. 6. Subscriptions: Creates a new subscription on an existing customer. Retrieves details about a specific active subscription for a customer. Updates an existing subscription on a customer. Cancels a customer's subscription. Lists active subscriptions. 7.Plans: Creates a plan. Retrieves a plan with the given ID. Updates the name a plan. Deletes a plan. Lists all plans. 8. Coupons: Creates a coupon. Retrieves a coupon with the given ID. Updates the metadata of a coupon. Deletes a coupon. Returns a list of coupons. 9. Discounts: Removes the currently applied discount on a customer. Removes the currently applied discount on a subscription. 10. Invoices: Creates an invoice. Retrieves the invoice with the give ID. Retrieves an invoice’s line items. Retrieves a customer’s upcoming invoice for a customer. Updates an existing invoice. Pays an invoice. Lists invoices for a specific customer. 11. Invoice items: Adds an arbitrary charge to the customer's upcoming invoice. Retrieves an invoice item with the given ID. Updates the amount or description of an upcoming invoice. Deletes an invoice item from the upcoming invoice. Lists all invoice items. 12.Transfers: Creates a new transfer. Retrieves the details of an existing transfer. Updates the specified transfer. Cancels a transfer. Lists all existing transfers. 13. Disputes: Updates a dispute. Closes a dispute for a charge. 14. Recipients: Creates a new recipient and verifies recipient's identity and bank account information or credit card. Retrieves the details of an existing recipient. Updates the specified recipient. Deletes a recipient. Lists all recipients. 15. Account: Retrieves the details of an account details. 16. Balance: Retrieves the current account balance. Retrieves the balance transection with the given ID. Returns a list of transections that have contributed to the Stripe account balance. 17. Application Fees: Retrieves the details of an application fee. Returns a list of application fees. 18. Application fee refunds: Refunds an application fee that has previously been collected but not yet refunded. Retrieves details about an application fee refund. Updates the specified application fee refund. Returns a list of the refunds that belonging to a specific application fee. 19. Events: Retrieves the details of an event. Lists all events. *Authentication* Stripe API is utilizing the Oauth2 as the authentication mechanism. Detailed information
Re: [Architecture] API import/export
Hi all, Thanks for all the feedback. I think for this version, we will be considering a single API import/export and capture only the API metadata within the exported archive. Will use swagger to capture much information as possible and keep stuff that cannot be captured by swagger 1.2 spec separately as files. Runtime data will not be captured by the archive for the initial implementation. Thanks, Lasantha On 24 November 2014 at 08:28, Sanjeewa Malalgoda sanje...@wso2.com wrote: IMO we should clearly identify what API meta data and run time data. Then we can identify what we need to consider for migration. If its single API import export we can consider metadata. If its platform migration we need to migrate both meta data and run time data. *Meta data:* API definition, Images, documents, tags, API scopes, attached sequences. Handler details *Run time Data:* Comments, rating, subscriptions, stats, Thanks, sanjeewa. On Fri, Nov 21, 2014 at 4:01 PM, Joseph Fonseka jos...@wso2.com wrote: Hi Lasantha IMO API comments and subscriptions should not be in the import/export it should be only limited to API definition , Management info and the documents. If you are exporting subscriptions it will require you to have the exact apps and users in the imported destination as well which will complicate the implementation usage. But as you mention there are some meta info which is not present in the swagger doc Ex: most of the management info like throttling and sequences and even the endpoints cannot be mapped to swagger 1.2. Swagger 2.0 allow you to define Vendor Extensions but for 1.2 I guess we have to find a workaround or define the additional information in a separate file. Regards Jo On Fri, Nov 21, 2014 at 3:32 PM, Lasantha Fernando lasan...@wso2.com wrote: Hi Jo, In that case, we will be using the swagger docs stored in registry to get the swagger definition when exporting and use the existing API to add/update when importing. I think there is a certain subset of metadata/information (captured after deploying the API) that is not captured by the swagger definition. But for this iteration, we will be only be focusing on the API definitions and not on other metadata that is added from store. Therefore +1 to go with swagger docs for keeping API definition. My only concern is whether this approach can be scaled if a requirement comes to capture other information related to APIs as well later (e.g. API comments, subscriptions etc). In such a case, can we keep the API definition itself in swagger format and keep any other artefacts that cannot be represented by swagger in a file format? WDYT? Thanks, Lasantha On 20 November 2014 14:36, Joseph Fonseka jos...@wso2.com wrote: Hi Lasantha Currently the add-api accepts swagger doc to create an API. So If we are using the existing services to import it is just a matter of posting the swagger to the add API. As Ajith pointed out the other issue is with API related meta data stored in DB Ex: scopes. If we use swagger we can represent them in a logical way instead of scattering them in multiple files. Thanks Jo On Thu, Nov 20, 2014 at 2:11 PM, Lasantha Fernando lasan...@wso2.com wrote: Hi, On 20 November 2014 13:36, Ajith Vitharana aji...@wso2.com wrote: On Thu, Nov 20, 2014 at 1:19 PM, Lasantha Fernando lasan...@wso2.com wrote: Hi Jo, Metadata related to the API is retrieved from registry RXT which stores it in XML format. Can't we put that metadata as XML as well to the archive and simply push it back to the registry when importing? For docs, we can use the swagger format. WDYT? At the API lifecycle (Design /Implement/Deploy) data going be stored in different places at same time . Eg: like registry databse/ AM database / Identity database / file system (API XML). So, directly pushing the XML format to registry will not work due that reason. We should use same APIs used in API publisher/store to deploy the API archives. That make consistency across all places for creating/managing APIs. Yes. Actually, what I meant was to keep the metadata in RXT in XML, but other related artifacts will be kept in a suitable format. Then at the time of importing, the APIs available at publisher/store will be used to deploy the archive. It won't be pushed to registry directly. Sorry for not communicating this clearly in the earlier response. Thanks, Lasantha -Ajith @Sanjeewa, +1 to consider the the single API import/export scenario. Regarding CApp deployer, there were some concerns raised by Sumedha in [1] earlier as well. I think the main concern was that modifications done to APIs after being deployed cannot be captured in a CAR file. Therefore I think we may have to go ahead with its own deployment model for this use case for now? Thanks, Lasantha [1] http://mail.wso2.org/mailarchive/architecture/2013-March/011049.html On 19
Re: [Architecture] APIM Support for getting Authorization header from query String
IMO we should add configuration to key validation entry point (in gateway authentication handler). With this configuration we should be able to decide token accept as query param, transport header or both. If query param authentication header enabled only we will retrieve token from query params. Otherwise we will be looking at transport headers. Or we may be able to look at both(transport header, query parameter) according to defined order. WDYT? Thanks, sanjeewa. On Mon, Nov 24, 2014 at 11:40 AM, Nuwan Dias nuw...@wso2.com wrote: In general, it is understood that it is bad practice. But its mentioned in the OAuth 2.0 spec, so IMO as a product we should support it but mention implications on the docs clearly. In scenarios where the communication between the client and server are guaranteed to be safe, its ok to pass the information in the url IMO. Ex: For systems communicating internally only. With the IoT stuff building up, I presume there could be more valid uses of this. Thanks, NuwanD. On Mon, Nov 24, 2014 at 11:33 AM, Gayan Gunawardana ga...@wso2.com wrote: On Sat, Nov 22, 2014 at 12:50 PM, Harsha Kumara hars...@wso2.com wrote: Hi, As Johann mentioned, if the specification defined sending token as the query param, we needs to support it and implement as specification specified. But again the user who going to use it needs to know aware of the security issues cause by using token as query param. Also the specification specified that it's discourage to use this approach. IMO If we support it, we shouldn't use in our products unless if there is any specific reason. What would be the particular use case to send access token in query String. This is a bad practice according to many real world use cases [1]. [1] http://www.thread-safe.com/2013/10/latest-facebook-security-vulnerability.html -- Gayan Gunawardana Software Engineer; WSO2 Inc.; http://wso2.com/ Email: ga...@wso2.com Mobile: +94 (71) 8020933 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- Nuwan Dias Associate Tech Lead - WSO2, Inc. http://wso2.com email : nuw...@wso2.com Phone : +94 777 775 729 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Sanjeewa Malalgoda* WSO2 Inc. Mobile : +94713068779 http://sanjeewamalalgoda.blogspot.com/blog :http://sanjeewamalalgoda.blogspot.com/ http://sanjeewamalalgoda.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] ESB Connector for Nest API
Ok thank you, I will go through with that. On Mon, Nov 24, 2014 at 1:50 PM, Shevan Goonetilleke she...@wso2.com wrote: Shakila, if you need to use a third party library for this pls follow the the following tread (from Isabelle) to get it approved: subject - Must-follow process to bring 3rd party libraries into the WSO2 platform On Mon, Nov 24, 2014 at 12:56 PM, Shakila Sivagnanarajah shak...@wso2.com wrote: I will send the milestone plan by today On Mon, Nov 24, 2014 at 12:52 PM, Samisa Abeysinghe sam...@wso2.com wrote: What is the milestone plan? Thanks, Samisa... Samisa Abeysinghe Vice President Delivery WSO2 Inc. http://wso2.com On Mon, Nov 24, 2014 at 12:48 PM, Shakila Sivagnanarajah shak...@wso2.com wrote: Hi All, I (shak...@wso2.com) have planned to develop $subject. Please find the project plan here, *Introduction: * Nest API is a real-time data API (connect people with devices in their homes), offering subscription based access to data shared by Nest-devices. The Nest clients (created to access Nest device data) will use Firebase. Firebase provides a real time data synchronization service. *Operations:* Nest Learning Thermostat - View current temperature - View or set target temperature - Set fan timer - View or set temperature mode - View humidity - View online status and last connection information Nest Protect Smoke + CO Alarm - View CO or smoke status - View battery health state - View last manual test status and timestamp for last manual test - View online status and last connection information Home - View a list of devices in the home - View energy event status (Rush Hour Rewards) - View or set Away state - View postal or zip code - Set ETA *Authentication:* OAuth 2.0 (authorization) *API Summary:* Nest API v1.1 *Documentation URL:* https://developer.nest.com/documentation -- Shakila Sivagnanarajah Associate Software Engineer Mobile :+94 (0) 770 760240 shak...@wso2.com -- Shakila Sivagnanarajah Associate Software Engineer Mobile :+94 (0) 770 760240 shak...@wso2.com -- Shevan Goonetilleke Director of Engineering WSO2, Inc. lean.enterprise.middleware m: +94777340680 w: http://wso2.com -- Shakila Sivagnanarajah Associate Software Engineer Mobile :+94 (0) 770 760240 shak...@wso2.com ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] ESB Connector for Teamwork
Hi all, I have planned to develop the $subject. Please find the project plan below. *Introduction* Teamwork API is a full RESTful API which allows you to interact with the data in your Teamwork account using HTTP calls( http://developer.teamwork.com/api). *Teamwork API Methods* *Account* Get Account Details The 'Authenticate' Call *Activity* Latest Activity across all projects List Latest Activity (for a project) Delete an activity entry *Companies * Create Company Update Company Delete Company Retrieve a Single Company Retrieve Companies Retrieving Companies within a Project *People* Add a new user Edit user Delete user Get Current User Details Get people Get all People (within a Project) Get a specific Person Permissions (within a Project) Get People (within a Company) Retrieve a Specific Person Retrieve a API Keys for all people on account *Permissions* Add a new user to a project Remove a user from a project Get a users permissions on a project Update a users permissions on a project *Projects* Create Project Update Project Delete Project Retrieve All Projects Retrieve a Single Project Retrieve your Starred Projects Star a project Unstar a project *Project Roles* List Roles on a Project *Milestones* List All Milestones List Milestones on a Project Get a Single Milestone Complete Uncomplete Create a Single Milestone Update Delete *Calendar Events* Get Events Get an Event Create event Edit event Delete event Get event types *Files* List Files on a Project Get a Single File Add a File to a Project Add a new File Version to a File Delete a File from a Project *Messages* Create a message Retrieve a Single Message Retrieve Latest Messages Update message Destroy message *Authentication* Authentication is managed using HTTP authentication (Basic). Kesavan Yogarajah Associate Software Engineer WSO2 Inc. Mob: +94 779758021 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Proposed Device Operations Flow of CDM
All, We've been working on this architecture for a long time now. Lets have a comprehensive review on Friday. I've already sent out the invite. On Mon, Nov 24, 2014 at 7:00 AM, Shan s...@wso2.com wrote: Hi all, Just to add some points . That depends on whether an agent is involved or not 3 criteria : 1 agent based 2 agent less 3 hybrid ( this is also based on feature ) If u look at Android It is 1 iOS 3 Windows 2 ( there is another option ) Some iot device its 1 Any Cpe device its 2 since for example routers use tr069 Things we need to consider 1 enrollment , de-enrollment (ui or non ui based , active or passive , ownership) 2 DM 3 transport 4 device stream Also the dmml - a new markup language to define the device feature which can be defined at the client agent or at the server based on os , platform , version . This can be based on some combination as well. The first one is based on the device itself the use case for that is an arduino which has some sensors connected . Sent from my iPhone On Nov 22, 2014, at 10:41 PM, Dilan Udara Ariyaratne dil...@wso2.com wrote: Hi Sameera, I am not exactly getting the point. It should be because I am not exactly aware of the actual use case of Windows and iOS. Do you mean that they are using different transport (or connectivity) protocols? Regards. *Dilan U. Ariyaratne* Software Engineer WSO2 Inc. http://wso2.com/ Mobile: +94775149066 lean . enterprise . middleware On Sat, Nov 22, 2014 at 9:29 PM, Sameera Perera samee...@wso2.com wrote: Hi Dilan On Windows and iOS we need to use the specific protocols and rely on the OS to execute the command. This is why we have to use this approach. (Sent from a mobile device) On 22 Nov 2014 19:29, Dilan Udara Ariyaratne dil...@wso2.com wrote: Hi All, Why do we need to construct a Platform-specific-payload at the server level? Cannot we just send the Platform-independent-payload to the device agent and invoke the corresponding feature operation at the client side? I might not be right because I am not exactly aware of all the use-cases. Appreciate if some valid use-cases can be provided on this regard. Thanks. *Dilan U. Ariyaratne* Software Engineer WSO2 Inc. http://wso2.com/ Mobile: +94775149066 lean . enterprise . middleware On Tue, Nov 18, 2014 at 8:32 AM, Harshan Liyanage hars...@wso2.com wrote: Hi Dilan, Yes. you are correct. Thanks, Lakshitha Harshan Software Engineer Mobile: *+94724423048* Email: hars...@wso2.com Blog : http://harshanliyanage.blogspot.com/ *WSO2, Inc. :** wso2.com http://wso2.com/* lean.enterprise.middleware. On Tue, Nov 18, 2014 at 7:20 AM, Dilan Udara Ariyaratne dil...@wso2.com wrote: Hi Harshan, This is with reference to the two merging options that you have mentioned in your previous reply to the thread. As I understood, with the 1st Option: You suggest to [1] convert platform-independent-payload to platform-specific-payload, save it and when another request comes in, [2] convert the platform-specific-payload back into its platform-independent-form and merge it with the platform-independent-payload for the new request and [3] convert that back to a platform-specific-payload. (Please correct me if I am wrong) So with this option, you suggest not to save a platform-independent-payload for the pending requests and deal with it only at run-time. As I understood, with the 2nd Option: You suggest to [1] Keep the platform-independent-payload saved along with its platform-specific-payload and when ever another request comes in, [2] Get the existing platform-independent-payload and merge it with new platform-independent-payload of the incoming request, save it and [3] Convert that to a new platform-specific-payload and overwrite the existing platform-specific-payload with the new one. (Please correct me if I am wrong) Thanks. *Dilan U. Ariyaratne* Software Engineer WSO2 Inc. http://wso2.com/ Mobile: +94775149066 lean . enterprise . middleware On Mon, Nov 17, 2014 at 8:16 AM, Harshan Liyanage hars...@wso2.com wrote: Hi, *Platform-specific payload *is the actual payload which will be delivered to the device when the device contacts the server for pending-operations. *Platform-independent *form is used to construct the *Platform-specific payload * communicate device operations internally within CDM. For example when an user sends a device operation using CDM web-console, *platform-independent *message will be sent from the console - CDM API - CDM Core - Device-platform bundle. Then the *device-platform bundle *will use it to construct the *platform-specific payload.* But there might be situation where some device operation payloads might not delivered to the device when another operation for that device comes-in. IMO in such cases its not good to have many pending *platform-specific payloads *for a single device. If we are to
[Architecture] ESB Connector For SlideShare
Hi All, I(va...@wso2.com) have planned to develop the $Subject. *Introduction* SlideShare API allows users to easily upload and share presentations, info-graphics, documents, videos, PDFs, and webinars. *API Methods* -Get Sideshow Information -Get Sideshows By Tag -Get Sideshows By Group -Get Sideshows By User -Sideshow Search -Get User Groups -Get User Favorites -Get User Contacts -Get User Tags -Edit Existing Sideshow -Delete Sideshow -Upload Sideshow -Add Favorite Sideshow -Check Favorite -Get Campaign information -Get Leads information For ALL Campaigns -Get Specific user Leads Information *Authentication* HTTP Basic Authentication For more Information about API follow this link http://www.slideshare.net/developers Thank you ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] APIM Support for getting Authorization header from query String
Hi Sanjeewa, Currently the key validation is done inside OAuthAuthenticator. what i’m planning to do is to get the key from query parameter if key is not available in the Authentication Header. regards On Mon, Nov 24, 2014 at 2:12 PM, Sanjeewa Malalgoda sanje...@wso2.com wrote: IMO we should add configuration to key validation entry point (in gateway authentication handler). With this configuration we should be able to decide token accept as query param, transport header or both. If query param authentication header enabled only we will retrieve token from query params. Otherwise we will be looking at transport headers. Or we may be able to look at both(transport header, query parameter) according to defined order. WDYT? Thanks, sanjeewa. On Mon, Nov 24, 2014 at 11:40 AM, Nuwan Dias nuw...@wso2.com wrote: In general, it is understood that it is bad practice. But its mentioned in the OAuth 2.0 spec, so IMO as a product we should support it but mention implications on the docs clearly. In scenarios where the communication between the client and server are guaranteed to be safe, its ok to pass the information in the url IMO. Ex: For systems communicating internally only. With the IoT stuff building up, I presume there could be more valid uses of this. Thanks, NuwanD. On Mon, Nov 24, 2014 at 11:33 AM, Gayan Gunawardana ga...@wso2.com wrote: On Sat, Nov 22, 2014 at 12:50 PM, Harsha Kumara hars...@wso2.com wrote: Hi, As Johann mentioned, if the specification defined sending token as the query param, we needs to support it and implement as specification specified. But again the user who going to use it needs to know aware of the security issues cause by using token as query param. Also the specification specified that it's discourage to use this approach. IMO If we support it, we shouldn't use in our products unless if there is any specific reason. What would be the particular use case to send access token in query String. This is a bad practice according to many real world use cases [1]. [1] http://www.thread-safe.com/2013/10/latest-facebook-security-vulnerability.html -- Gayan Gunawardana Software Engineer; WSO2 Inc.; http://wso2.com/ Email: ga...@wso2.com Mobile: +94 (71) 8020933 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- Nuwan Dias Associate Tech Lead - WSO2, Inc. http://wso2.com email : nuw...@wso2.com Phone : +94 777 775 729 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Sanjeewa Malalgoda* WSO2 Inc. Mobile : +94713068779 http://sanjeewamalalgoda.blogspot.com/blog :http://sanjeewamalalgoda.blogspot.com/ http://sanjeewamalalgoda.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Sam Sivayogam* Software Engineer Mobile : +94 772 906 439 Office : +94 112 145 345 *WSO2, Inc. :** wso2.com http://wso2.com/* lean.enterprise.middleware. ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] YouTube Connector for WSO2 ESB
Hi All, I've planed to develop $subject. *Introduction* YouTube is a video-sharing website. The site allows users to upload, view, and share videos. *YouTube API Methods**Activities* - *ChannelBanners* - *Channels* - *ChannelSections* - *GuideCategories* - *i18nLanguages* - *i18nRegions* - *PlaylistItems* - *Playlists* - *Search* - *Subscriptions* - *Thumbnails* - *VideoCategories* - *Videos* - *Watermarks* - *Channel Reports* Link to YouTube API : http://api-portal.anypoint.mulesoft.com/youtube/api/youtube-data-api-v30/docs/reference Regards, -- *Naasheer Ali* | Associate Software Engineer WSO2, Inc |#20, Palm Grove, Colombo 03, Sri Lanka Email: naashe...@wso2.com ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Integrating ntask component into ESB
According to the offline chat I had with Anjana, we are going to load the tenant as required when executing the task. On Wed, Oct 1, 2014 at 12:04 PM, Anjana Fernando anj...@wso2.com wrote: I hope you understood, what I told is, not what you mentioned earlier, you do not have to store anything in the registry, and the ESB does not have to load anything themselves. The tasks will be automatically loaded. Cheers, Anjana. On Wed, Oct 1, 2014 at 12:00 PM, Malaka Silva mal...@wso2.com wrote: Hi Anjana, Yes that is the plan. Will be implementing this at the task adapter level. Best Regards, Malaka On Wed, Oct 1, 2014 at 11:23 AM, Anjana Fernando anj...@wso2.com wrote: Hi Malaka, Kasun sometime earlier asked me about this; And basically, from ntask, the tasks will automatically start up when the server is started up. It does not wait till a tenant is loaded or anything like that, it is automatically handled by ntask. If the task itself wants some tenant specific functionalities, the task implementation can load that. Basically, the ESB has an task adapter implementation, which bridges the ntask task interface and ESB task interfaces, in the adaptor, you can write the code to load any tenant information as needed. Cheers, Anjana. On Wed, Oct 1, 2014 at 8:58 AM, Malaka Silva mal...@wso2.com wrote: Hi All, At the time of inbound EP code review Azeez has identified an issue with ntask integration in tenant mode. The problem is when a task is schedules in tenant mode this will not run until the tenant is loaded. Following is the solution I'm planning to implement. When a task is scheduled it'll put a entry in the registry, under tenant specific structure. At the time ESB starts, we are going to load the tenant, if they have one or more tasks scheduled. Above will solve the task implementation and polling inbound EPs issue in tenant mode. But the issue will still exists for listening Inbound EPs. Let me know your feedback on this? Best Regards, Malaka On Tue, May 20, 2014 at 5:37 PM, Ishan Jayawardena is...@wso2.com wrote: We have implemented the $subject and it is available in the ESB's git repo. As we initially planned we will be releasing this new task manager with our next release. Thanks, Ishan. On Mon, Apr 21, 2014 at 5:27 PM, Ishan Jayawardena is...@wso2.com wrote: Today we had a discussion to review the current implementation of $subject. We have developed two task providers/managers to manage quartz and ntask based task types. The correct task manager gets registered according to the synapse configuration, during the startup. When a user deploys a new task through the UI, Synapse schedules a task in the registered task manager. Although each task manager is capable of executing its own task type, currently none of the task managers can execute tasks of a different type. Due to this, the new ntask task manager cannot execute existing tasks such as Synapse MessageInjector. We cannot support this yet without Synapse having a dependency to ntask component. At the moment we are looking into a solution to this problem. At the same time, we are working on the inbound endpoint (VFS) to make it reuse the same ntask provider that we developed. Thanks, Ishan. On Mon, Apr 21, 2014 at 9:42 AM, Ishan Jayawardena is...@wso2.com wrote: Hi Kasun, We managed to solve the issue and now we are working on the final stage of the development. We will complete this within this week. Thanks, Ishan. On Tue, Apr 15, 2014 at 9:48 AM, Kasun Indrasiri ka...@wso2.com wrote: Did you check whether the required packages are osgi imported properly? On a separate note, what's the ETA of a working deliverable of this? On Sun, Apr 13, 2014 at 12:43 PM, Anjana Fernando anj...@wso2.com wrote: Obviously, check if that class is available and where it is referred from in the code. As I remember, there isn't a package called ntaskint, so check where this is coming from. Cheers, Anjana. On Sat, Apr 12, 2014 at 6:46 AM, Ishan Jayawardena is...@wso2.com wrote: We developed the quartz task manager and we are currently working on the ntask task manager. While developing the task handling component that uses ntask, we observed that we cannot schedule a task in it due to a class not found error. See the below error message. The ntask component (which is used by the component that we are currently writing) cannot load the actual task implementation. Does anyone know how to get rid of this? java.lang.ClassNotFoundException: class org.wso2.carbon.ntaskint.core.Task at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:501) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:421) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:412) at
[Architecture] CDM feature publishing and bundle interaction
Hi all,
A feature in CDM is what defines a command that can be executed on a
device. When applying a command on a device there can 4 factors to consider
to decide if it can be / should be applied or not. These are based on ,
If Operating system support the command + Operating system version support
the command + device platform support the command + A specific
device support the command
Proposed CDM will contain a set of platform(iOS, Android, Windows) specific
bundles which will reside in the middle of a device and the CDM core[1][2].
When a command is applied on a device by a user through CDM console, the
device specific bundle is responsible for converting the command to a
platform *dependent* payload that a device can understand.
With the proposed architecture, there can be few ways to define a feature,
implementation details of it.
1. Server's device specific bundles describes the feature and the way to
implement it.
For example: If the Admin needs to apply a command on a device through CDM
console. Server must know,
- Details of the feature
- Permitted/required values to apply the command
- The final format of the command that a device can understand.
For instance, If the user needs to reduce volume of a device to 0, the
server must know a command called,
- Volume
- Permitted range is 0-100
- Format the device accepts the command
All the above values are stored in the server. This method is necessary to
handle, devices that doesn't allow an agent to perform MDM operations,
rather it is *done through the OS it-self**. *In this case, all the
features and their payloads are pre-defined in the server.
2. Client send the commands it supports *along with some implementation
details(meta-data)*. This method is suitable for *Agent based system* such
as Andoid and Arduino since the client can send the commands list it
supports and some meta data about the commands. Bellow diagrams describe,
how a device with a CDM agent, first sends commands and meta-data and how
the admin/user apply a command on a device.
*Agent publishing supported features*
1. At the time of registration or when the supported commands change, the
Agent sends the command list to corresponding server connector(API)
together with meta-data on how to process it.
For example: A client might send, {FeatureCode:volume,
DataType:Integer, MinValue:0, MaxValue:100}
2. Corresponding platform bundle receives the payload. Data is converted
to its platform independent format.
3. Data is forwarded to CDM Core
4. Finally saved to the database
Since the command is self-describing, any new command can be understood by
the server and interpreted. Due to the flexibility of this mechanism, when
a new feature is added to an agent, that is not defined in the server;
server can still recognize the command, allow user to apply the command on
devices. This extensibility is very useful in IoT scenario.
*Admin, applying a feature on a device*
1. Admin applies a command on a device through CDM console. such
as {FeatureCode:volume, value:0}
2. Core check for permission to apply/perform the command and the request
is saved.
3. Core invokes the relevant platform specific bundle to handle the request
and passes a device independent payload
4. Platform specific reply is created according to the values sent by the
core. This platform specific payload is created based on a template stored
in the server. If a template is not available(new command), a generic
response will be sent based on the value to be sent.
5. Core puts it to the output queue, so that the device may retrieve it.
The template mentioned in step 4 is the format the device expect the
command. For agent based devices, this format can be a common one such as a
JSON object, but for agentless devices such as Windows phones it will be
different. Admin can edit this template, through the CDM console. Also the
server will be able to restrict certain features from a device, even though
the device support the features.
3. Hybrid approach. Combination of both the above mentioned methods are
necessary for some devices such as iOS devices, where some device
management features can be done through the agent, but some are done
through the server. This is due to the fact that some operations are
pre-defined, by the Operating system it-self, and the payload formats and
command code are defined, by the OS it-self. But some of the command are
not defined by the OS, therefore Agent is required to perform those
operation.
[1] Proposed Architecture of CDM [Architecture]
[2] Proposed Device Operations Flow of CDM[Architecture]
Regards,
Inosh
--
Inosh Perera
Software Engineer, WSO2 Inc.
Tel: 0785293686
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] YouTube Connector for WSO2 ESB
What is the usecase here? Why anyone would want to use this connector in an ESB configuration? On Monday, November 24, 2014, Naasheer Ali naashe...@wso2.com wrote: Hi All, I've planed to develop $subject. *Introduction* YouTube is a video-sharing website. The site allows users to upload, view, and share videos. *YouTube API Methods**Activities* - *ChannelBanners* - *Channels* - *ChannelSections* - *GuideCategories* - *i18nLanguages* - *i18nRegions* - *PlaylistItems* - *Playlists* - *Search* - *Subscriptions* - *Thumbnails* - *VideoCategories* - *Videos* - *Watermarks* - *Channel Reports* Link to YouTube API : http://api-portal.anypoint.mulesoft.com/youtube/api/youtube-data-api-v30/docs/reference Regards, -- *Naasheer Ali* | Associate Software Engineer WSO2, Inc |#20, Palm Grove, Colombo 03, Sri Lanka Email: naashe...@wso2.com javascript:_e(%7B%7D,'cvml','naashe...@wso2.com'); -- S.Uthaiyashankar VP Engineering WSO2 Inc. http://wso2.com/ - lean . enterprise . middleware Phone: +94 714897591 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] ESB Connector For SlideShare
Can you give more information on the usecase? An example scenario on when to use this connector? Why people would want to upload slides through ESB? On Monday, November 24, 2014, Vanii Thiyagarajah va...@wso2.com wrote: Hi All, I(va...@wso2.com javascript:_e(%7B%7D,'cvml','va...@wso2.com');) have planned to develop the $Subject. *Introduction* SlideShare API allows users to easily upload and share presentations, info-graphics, documents, videos, PDFs, and webinars. *API Methods* -Get Sideshow Information -Get Sideshows By Tag -Get Sideshows By Group -Get Sideshows By User -Sideshow Search -Get User Groups -Get User Favorites -Get User Contacts -Get User Tags -Edit Existing Sideshow -Delete Sideshow -Upload Sideshow -Add Favorite Sideshow -Check Favorite -Get Campaign information -Get Leads information For ALL Campaigns -Get Specific user Leads Information *Authentication* HTTP Basic Authentication For more Information about API follow this link http://www.slideshare.net/developers Thank you -- S.Uthaiyashankar VP Engineering WSO2 Inc. http://wso2.com/ - lean . enterprise . middleware Phone: +94 714897591 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] ESB Connector for Teamwork
Can you give a usecase for this connector? On Monday, November 24, 2014, Kesavan Yogarajah kesav...@wso2.com wrote: Hi all, I have planned to develop the $subject. Please find the project plan below. *Introduction* Teamwork API is a full RESTful API which allows you to interact with the data in your Teamwork account using HTTP calls( http://developer.teamwork.com/api). *Teamwork API Methods* *Account* Get Account Details The 'Authenticate' Call *Activity* Latest Activity across all projects List Latest Activity (for a project) Delete an activity entry *Companies * Create Company Update Company Delete Company Retrieve a Single Company Retrieve Companies Retrieving Companies within a Project *People* Add a new user Edit user Delete user Get Current User Details Get people Get all People (within a Project) Get a specific Person Permissions (within a Project) Get People (within a Company) Retrieve a Specific Person Retrieve a API Keys for all people on account *Permissions* Add a new user to a project Remove a user from a project Get a users permissions on a project Update a users permissions on a project *Projects* Create Project Update Project Delete Project Retrieve All Projects Retrieve a Single Project Retrieve your Starred Projects Star a project Unstar a project *Project Roles* List Roles on a Project *Milestones* List All Milestones List Milestones on a Project Get a Single Milestone Complete Uncomplete Create a Single Milestone Update Delete *Calendar Events* Get Events Get an Event Create event Edit event Delete event Get event types *Files* List Files on a Project Get a Single File Add a File to a Project Add a new File Version to a File Delete a File from a Project *Messages* Create a message Retrieve a Single Message Retrieve Latest Messages Update message Destroy message *Authentication* Authentication is managed using HTTP authentication (Basic). Kesavan Yogarajah Associate Software Engineer WSO2 Inc. Mob: +94 779758021 -- S.Uthaiyashankar VP Engineering WSO2 Inc. http://wso2.com/ - lean . enterprise . middleware Phone: +94 714897591 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] ESB Connector for Nest API
Need usecase for this. On Monday, November 24, 2014, Shakila Sivagnanarajah shak...@wso2.com wrote: Hi All, I (shak...@wso2.com javascript:_e(%7B%7D,'cvml','shak...@wso2.com');) have planned to develop $subject. Please find the project plan here, *Introduction: * Nest API is a real-time data API (connect people with devices in their homes), offering subscription based access to data shared by Nest-devices. The Nest clients (created to access Nest device data) will use Firebase. Firebase provides a real time data synchronization service. *Operations:* Nest Learning Thermostat - View current temperature - View or set target temperature - Set fan timer - View or set temperature mode - View humidity - View online status and last connection information Nest Protect Smoke + CO Alarm - View CO or smoke status - View battery health state - View last manual test status and timestamp for last manual test - View online status and last connection information Home - View a list of devices in the home - View energy event status (Rush Hour Rewards) - View or set Away state - View postal or zip code - Set ETA *Authentication:* OAuth 2.0 (authorization) *API Summary:* Nest API v1.1 *Documentation URL:* https://developer.nest.com/documentation -- Shakila Sivagnanarajah Associate Software Engineer Mobile :+94 (0) 770 760240 shak...@wso2.com javascript:_e(%7B%7D,'cvml','shak...@wso2.com'); -- S.Uthaiyashankar VP Engineering WSO2 Inc. http://wso2.com/ - lean . enterprise . middleware Phone: +94 714897591 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] ESB Connector for ZOHO Invoice
Can you propose the usecase please On Monday, November 24, 2014, Sriashalya Srivathsan asha...@wso2.com wrote: ok ,noted,I'll consider the main methods only,Thank you. On Mon, Nov 24, 2014 at 1:43 PM, Shevan Goonetilleke she...@wso2.com javascript:_e(%7B%7D,'cvml','she...@wso2.com'); wrote: Ashalya, there are a lot of methods here which may not be doable in 3 weeks. Pls identify the main use cases around this app and build methods related to those. On Mon, Nov 24, 2014 at 1:04 PM, Sriashalya Srivathsan asha...@wso2.com javascript:_e(%7B%7D,'cvml','asha...@wso2.com'); wrote: I have planned to develop the $subject.Please find the project plan below. *Introduction* Zoho Invoice API gives the programmatic access to the Zoho Invoice service, allows to expand and build on the Zoho Invoice platform for small businesses across the globe[1]. *API Operations* *Contacts* -List contacts -Get contact -Create a contact -Update a contact -Delete a contact -Mark as active -Mark as inactive -Enable payment reminders -Disable payment reminders -Email statement -Get statement mail content -Email contact -List comments -List refunds *Estimates* -List estimates -Get an estimate -Create an estimate -Update an estimate -Delete an estimate -Mark an estimate as sent -Mark an estimate as accepted -Mark an estimate as declined -Email an estimate -Email an estimate -Get estimate email content -Bulk export estimates -Bulk print estimates -Update billing address -Update shipping address -List estimate template -Update estimate template *Invoices* -List invoices -Get an invoice -Create an invoice -Update an invoice -Delete an invoice -Mark an invoice as sent -Void an invoice -Mark as draft -Email an invoice -Email invoices -Get invoice email content -Remind customer -Bulk invoice reminder -Get payment reminder mail content -Bulk export invoices -Bulk print invoices -Disable payment reminder -Enable payment reminder -Write off invoice -Cancel write off -Update billing address -Update shipping address -List invoice templates -Update invoice template *Payment and credit* -List invoice payments -List credits applied -Apply credits -Delete a payment -Delete applied credit *Attachment* -Get an invoice attachment -Add attachment to an invoice -Update attachment preference -Delete an attachment -Delete the expense receipt *Recurring Invoices* -List recurring invoices -Get a recurring invoice -Create a recurring invoice -Update a recurring invoice -Delete a recurring invoice -Stop a recurring invoice -Resume a recurring invoice -Update recurring invoice template -List recurring invoice history *Credit Notes* -List credit notes -Get credit note -Create a credit note -Update credit note -Delete credit note -Convert to open -Void credit note -Email credit note -Email history -Get email content -Update billing address -Update shipping address -List credit note template -Update credit note template *Apply to invoice* -List invoices credited -Credit to an invoice -Delete invoices credited *Refunds* -List credit note refunds -List refunds of a credit note -Get credit note refund -Refund credit note -Update credit note refund -Delete credit note refund Customer Payments -List customer payments -Get a customer payment -Create a customer payment -Update a customer payment -Delete a customer payment Expenses -List expenses -Get an expense -Create an expense -Update an expense -Delete an expense -List expense comments history *Receipt* -Get an expense receipt -Add receipt to an expense -Delete a receipt *Authentication* Supports authtoken [1]https://www.zoho.com/invoice/api/v3 -- Shevan Goonetilleke Director of Engineering WSO2, Inc. lean.enterprise.middleware m: +94777340680 w: http://wso2.com -- S.Uthaiyashankar VP Engineering WSO2 Inc. http://wso2.com/ - lean . enterprise . middleware Phone: +94 714897591 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Fwd: Stripe Web Connector for WSO2 ESB
Need usecase please. On Monday, November 24, 2014, Keerthika Mahendralingam keerth...@wso2.com wrote: Ok noted. I will create the milestone plan accordingly. On Mon, Nov 24, 2014 at 1:52 PM, Shevan Goonetilleke she...@wso2.com javascript:_e(%7B%7D,'cvml','she...@wso2.com'); wrote: Keerthika, there are a lot of methods here too...pls define the some useful scenarios around this and implement only those methods (given that you have only 3 weeks to complete). On Mon, Nov 24, 2014 at 12:54 PM, Keerthika Mahendralingam keerth...@wso2.com javascript:_e(%7B%7D,'cvml','keerth...@wso2.com'); wrote: I will share the milestone plan by today evening. On Mon, Nov 24, 2014 at 12:53 PM, Samisa Abeysinghe sam...@wso2.com javascript:_e(%7B%7D,'cvml','sam...@wso2.com'); wrote: Milestone plan for this? Thanks, Samisa... Samisa Abeysinghe Vice President Delivery WSO2 Inc. http://wso2.com On Mon, Nov 24, 2014 at 12:49 PM, Keerthika Mahendralingam keerth...@wso2.com javascript:_e(%7B%7D,'cvml','keerth...@wso2.com'); wrote: Hi all, I have planned to develop $subject as described below. *Introduction* Stripe provides simple RESTful HTTP interfaces to handle payments. *Stripe API Methods* 1. Cards: Creates a new card for a customer. Retrieves an existing card details stored on a customer. Updates a card details. Deletes a card. Lists all cards belonging to a customer. 2. Tokens: Creates a card token that wraps the details of a credit card. Creates a bank account token that wraps the details of a bank account. Retrieves an existing token. 3. Customers: Creates a new customer. Retrieves the details of an existing customer. Updates the specified customer. Permanently deletes a customer. Returns a list of all customers. 4. Charges: Creates a new charge. Retrieves the details of an existing charge. Updates the specified charge. Captures the payment of an existing charge. returns a list of all charges. 5. Refunds: Creates a new refund for a charge. Retrieves details about an existing refund. Updates the specified refund. Returns a list all refunds belonging to a specific charge. 6. Subscriptions: Creates a new subscription on an existing customer. Retrieves details about a specific active subscription for a customer. Updates an existing subscription on a customer. Cancels a customer's subscription. Lists active subscriptions. 7.Plans: Creates a plan. Retrieves a plan with the given ID. Updates the name a plan. Deletes a plan. Lists all plans. 8. Coupons: Creates a coupon. Retrieves a coupon with the given ID. Updates the metadata of a coupon. Deletes a coupon. Returns a list of coupons. 9. Discounts: Removes the currently applied discount on a customer. Removes the currently applied discount on a subscription. 10. Invoices: Creates an invoice. Retrieves the invoice with the give ID. Retrieves an invoice’s line items. Retrieves a customer’s upcoming invoice for a customer. Updates an existing invoice. Pays an invoice. Lists invoices for a specific customer. 11. Invoice items: Adds an arbitrary charge to the customer's upcoming invoice. Retrieves an invoice item with the given ID. Updates the amount or description of an upcoming invoice. Deletes an invoice item from the upcoming invoice. Lists all invoice items. 12.Transfers: Creates a new transfer. Retrieves the details of an existing transfer. Updates the specified transfer. Cancels a transfer. Lists all existing transfers. 13. Disputes: Updates a dispute. Closes a dispute for a charge. 14. Recipients: Creates a new recipient and verifies recipient's identity and bank account information or credit card. Retrieves the details of an existing recipient. Updates the specified recipient. Deletes a recipient. Lists all recipients. 15. Account: Retrieves the details of an account details. 16. Balance: Retrieves the current account balance. Retrieves the balance transection with the given ID. Returns a list of transections that have contributed to the Stripe account balance. 17. Application Fees: Retrieves the details of an application fee. Returns a list of application fees. 18. Application fee refunds: Refunds an application fee that has previously been collected but not yet refunded. Retrieves details about an application fee refund. Updates the specified
Re: [Architecture] ESB Connector for Nimble
What is the usecase On Monday, November 24, 2014, Elilmatha Sivanesan elilma...@wso2.com wrote: Hi All, I have planned to develop the $subject.Please find the project plan below. Introduction Nimble is a social relationship management tool that brings together your contacts from many disparate locations into one place; gives you a dynamic, 360º view of each contact; and helps you nurture the new and important contacts in your network. Nimple API Operations CONTACTS API Basic Contacts API List contact - List contacts - List contacts ids Search contacts - Search contacts - Saved search contacts - create Saved search contacts - update Saved search contacts - delete Saved search contacts Create contacts - create contacts Get contacts - Get contacts details Update contacts - Update contacts Delete contacts - Simple contact delete - Advanced contact delete Contacts Notes API Show single note - Get single note List note - Get contact note list create note - Create contact note Update note - Update contact note Delete note - delete single note Contacts METADATA API Retrieve all meta data - List all contacts meta data (groups and fields) Create field - Create field Update field - Update field Delete field - Delete field Create group - Create field group Update group - Update field group Delete group - Delete field group ACTIVITIES API Task API - Create task Authentication Supports OAuth 2.0 protocol -- *S.Elilmatha* Associate Software Engineer, WSO2 Inc.; http://wso2.com lean.enterprise.middleware Mobile 0779842221. -- S.Uthaiyashankar VP Engineering WSO2 Inc. http://wso2.com/ - lean . enterprise . middleware Phone: +94 714897591 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] carbon kernel identity.xml is not compatible with oAuth feature 4.2.3
Hi, Stratos products get the identity.xml from the carbon kernel 4.2.0 which is not compatible with oAuth feature 4.2.3 and 4.2.0(I have not tried with other versions). I had to copy the oAuth section of identity.xml of the IS 4.5.0 in order to resolve the issue. Two alternatives are possible, what is the best way? 1) update kernel with compatible configurations 2) individual products has their own identity.xml. In this way individual product has to update every time when a change is occurred from IS side. -- Udara Liyanage Software Engineer WSO2, Inc.: http://wso2.com lean. enterprise. middleware web: http://udaraliyanage.wordpress.com phone: +94 71 443 6897 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
