SW-29199 - USA (Arizona) - Enterprise Service Bus and Application Programming Interface (API) Development and Enablement Platform - Deadline December 4,2019

Product (RFP/RFQ/RFI/Solicitation/Tender/Bid Etc.) ID: SW-29199

Government Authority located in Tempe, Arizona; USA based organization looking for expert vendor for enterprise service bus and application programming interface (API) development and enablement platform.

[A] Budget: Looking for proposal

[B] Scope of Service:

(1) Vendor needs to provide enterprise service bus on-premise technology platform as the application product to connect ASU systems as well as creating APIs and other web-services for a variety of business functions.
• Connector:
- Respondent must have adapters and connectors to commonly used endpoints such as files, databases, HTTP, SFTP and also include connectors to popular third-party products such as many of those listed.
• Message exchange patterns:
- Respondent must support a variety of both synchronous and asynchronous data exchanges including request-response, request-call-back, one-way a synch, publish and subscribe.
• Communication and message structure:
- Respondent must support standards-based integrations using protocols and message formats such as AS2, (s)FTP, HTTP(s), SMTP, XML, XSD, SOAP, REST, JSON, and other common resource
• Transformations:
- Respondent should have the capability to transform data between common formats such as but not limited to: XML, XSLT, JSON, CSV, EDI (ANSI X.12, EDIFACT, XML), and inputs from data pulled from common databases and enterprise applications.
•Scripting language:
- Respondent should support at least one type of proprietary or preferably a standards-based scripting language such as JavaScript, Python, Ruby, or Groovy.
• Routing and flow control:
- Respondent must allow for various routing options of the message. This includes different routings based on data values or content type.
• Polling:
- Respondent should support a mechanism for polling for items and endpoints based on a given scheduling strategy.
• Change data capture:
- Respondent should have a mechanism to monitor or trigger events when changes occur to enterprise data sources.
• Batch:
- Respondent should support batch jobs for processing large datasets in an asynchronous manner.
• Queue:
- Respondent should include a message queueing technology or support some common third-party queues such as: RabbitMQ, ActiveMQ, amazon simple queue service, and azure queue. Queue support should include both publish and subscribe.
• Stateless business process:
- A stateless business process is one that does not persist its state to a database. Respondent must support these stateless logical transactions.
• Stateful business processes:
- Stateful business processes are usually more complex with long running logic where the state is maintained over a period of time such as hours and days and weeks, usually waiting for a triggering event to resume business processing.
• Custom coding:
- Respondent should have a facility to allow for custom developed transformations, custom business processing logic, and custom routing logic.
• Real-time monitoring:
- Respondent should support a dashboard or similar interface which can be used to gain insights into ESB flow deployments and their activity over time.
• Logging:
- Respondent must have the capability to log information at various points of an ESB flow, including to Splunk which is used at ASU extensively for logging, alerting, and general application reporting.
• Authentication methods:
- Respondent should support common authentication methods including but not limited to Basic Auth, OAuth 2.x, SAML, Kerberos, and LDAP.
• Authorization methods:
- Respondent should support access control such as role based or attribute-based; or integrating to common identity and authorization products which support these methods.
• Performance:
- Respondent must describe general performance expectations for the platform and what options exist to change the relative performance configuration as needs may change. Describe how the platform can scale and if the option exists for dynamic performance scaling.
• Quality of service:
- Respondent must allow an architecture design that allows for the incorporation of fault tolerance. This may include load balancing, utilizing clustering deployments, creation of separate domains, or other high-availability and disaster recovery architectures.
(2) All the questions must be submitted no later than November 15, 2019
(3) The contract period will be for one year.
(4) Pre-bid conference will be held on November 7, 2019  

[C] Eligibility:

Onshore (USA Only)

[D] Work Performance:

Not Applicable

Expiry Date : Wednesday, 4 December, 2019

Pre-proposal Conference Date : Thursday, 7 November, 2019

Question Answer Deadline : Friday, 15 November, 2019

Category : Software, System and Application

Country : USA

State : Arizona

RFP Expired

You can either pay for Single RFP/Bid document or Subscribe with Monthly Subscription for whole Software, System and Application Category/Categories.

If you will obtain monthly subscription for Software, System and Applicationcategory/categories, you will be able to access all the RFPs from that Category. Here are the Monthly Subscription offers. So, subscribe for Monthly offers and get rid of Individual RFP payment.

*No commitment =
(1) There is no minimum commitment.
(2) You can subscribe for as less as 1 month and cancel it any time. If you subscribe for annual offer, you can cancel it any time within year.
(3) There is no partial refund policy after Monthly or Annual subscription. You will be required to use services for a Month (Or Year since you have availed discounted pricing).
(4) You can cancel your subscription any-time directly from your PayPal account to stop further recurring charges before next due date.
(5) You will be able to download all RFPs for subscribed Category or Location without any extra cost.

Similar RFPs