Mulesoft vs Service Guard

Sr No Feature Comparison mulesoft Service Guard Response

1

REST API definitions: Single/dual verb (i.e., GET, POST only) Four verbs (POST, GET, PUT, DELETE) Hypermedia as <rel> headers Hypermedia within the payload XML payloads JSON payloads XHTML payloads Query strings URI patterns yes Yes

2

The Proposed Solution shall provide other API types such as SOAP, JMS, AMQP, all commonly used MOMs including WMQ, ActiveMQ, RSS, Atom, XMPP, and MQTT. yes Yes

3

Additional verbs (e.g. PATCH, HEAD, OPTIONS) Custom media types Compressed payloads (e.g. zip) Digital signatures S/MIME attachments (signatures/encryption) Multipart messages yes Yes

4 RAML or Swagger yes yes 5 a) SOAP yes Yes 6 b) WSDL yes Yes 7 c) WS*Addressing yes Yes

8 d) WS*Security yes

WS Security ( partner to SG) WS Security (partner-‐SG -‐ resuource)

WS Security (SG -‐ resuource) 9 e) WS*Policy yes in future release. However SG comes

10 f) WS*Basic Profile yes with JSON encryption for RESTFUL WADL services from web and mobile native. This is apparently the need of the market from mobile. SOAP WS-‐Security is getting less popular now.

11 g) WS*Security Policy yes

12 h) WS*Reliable Messaging yes

13

The Proposed Solution shall provide the use of the specification of APIs throughout the API lifecycle, across API design, implementation, runtime, monitoring, management, and engagement. yes Yes

14 a) API Versioning yes Yes 15 b) API Policy enforcements yes Yes 16 c) API Application Registration yes Yes 17 d) API Contract Management and Approvals yes Yes

18 The Proposed Solution shall provide the ability for creating new APIs from existing applications and services yes

Enrichment(adding new params in method signature,add new params in

class, add new signature)

19

The Proposed Solution shall provide a graphical data mapping tool to map and transform uests and responses between REST, SOAP, and other API styles. yes Yes

20

The Proposed Solution shall provide the exposure APIs over the following message formats: a) XML b) JSON c) File d) CSV e) Excel (.xls) f) POJO g) EDIFACT h) X12 i) Maps j) MTOM / XOP k) Fixed-‐length file yes Yes

21 The Proposed Solution shall provide for creating SLA tiers for different API consumers yes Yes

22 The Proposed Solution shall provide the enforcements of the following API policies. Please describe each in detailed: yes

23 a) Client ID enforcement yes Yes 24 b) Cross-‐Origin Resource Sharing yes Yes 25 c) Rate-‐limiting yes Yes 26 d) Rate-‐limiting, SLA-‐Based yes yes 27 e) Throttling yes yes 28 f) Throttling, SLA-‐Based yes yes 29 g) HTTP Basic Authentication yes yes 30 h) IP Blacklist yes yes 31 i) IP Whitelist yes yes 32 j) JSON Threat Protection yes yes 33 k) XML Threat Protection yes yes

34 l) LDAP Security Manager yes yes. AD/LDAP can be added in.

35 m) OAuth 2.0 Access Token Enforcement yes

not supported as it is an enterprise software where the partners are also companies. Another reason is we offer Multil factor 2FA login where Certificate or One Time Passowrd with geo fencing and device profiling is enforeced to

ensure the partner is the right company/person coming in.

36 n) OAuth 2.0 Provider yes same as above.

37 o) PingFederate access token enforcement yes

We can provide ADFS (Active Directory Federated Services) support where can comply with all the leading enterpries

solutions in the world.

38 The Proposed Solution shall provide API Analytics capabilities and be able to track the following metrics: yes yes

39 a) Transactions per second yes yes 40 b) Latency yes yes 41 c) uest size yes yes 42 d) Response size yes yes 43 e) Error rates yes yes. this is default feature 44 f) Policy violations yes yes. this is default feature 45 g) SLA tier errors yes

46 The Proposed Solution's analytics feature shall allow users to filter the above metrics by: yes yes. this is default feature

47 a) Response type yes yes. this is default feature 48 b) Client OS yes yes. this is default feature 49 c) Client browser yes yes. this is default feature

50 d) API versions yes yes. this is default feature 51 e) API user/application yes yes. this is default feature

52 f) Geography yes

we have standard comprehensive list of reports and also we have exposed APIs for data mining which can be used by

any BI tool. So the access to data can be made available customized reports and Analytics. Said that we have the reports and if needed we can add more as per

your requirement.

53 The Proposed Solution's analytics feature shall allow users to easily create custom dashboards and charts yes yes. this is default feature

54 The Proposed Solution shall provide integration to the organization's LDAP directory for users of The Proposed yes

yes. for each api there can be description, error codes, usage, comments can be added manual.

55 Solutions. yes yes. this is default feature

56 yes we are adding this into the feature release of our up coming version.

57 The Proposed Solution shall provide a configurable API Portal for API documentation. yes

yes. for each api there can be description, error codes, usage, comments can be added manual.

58 The Proposed Solution shall provide auto-‐generation of documentations from the API specifications design. yes yes

59

The Proposed Solution shall provide the functionality expansion for Open API Management and Monetization. The Tenderer shall provide detail explanation how the solution can be extended for Open API Management and compatible to integrate with multiple implementations of APIs and other EAI/SOA solution yes

we are adding this into the feature release of our up coming version.

60

The Proposed Solution shall create a variety of rate plans (e.g. prepaid plans, post-‐paid plans, fixed-‐fee plans) that charge users for the use of the APIs yes yes

61 The Proposed Solution shall provide reporting and billing facilities which includes: yes

62 a) Summary or detailed reports on traffic to APIs for which users purchased a rate plan yes yes

63 b) Create billing documents for the use of the APIs and publish those documents to users yes yes

64

The Proposed Solution shall set limits to help control and monitor the performance of the APIs and automatic notifications will be send to the System administrator when the limit is approached or reached. yes yes

65

The Proposed Solution shall set limits to help control the number of API calls for each API and automatic notifications will be send to the users when the limit is approached or reached. yes yes

66 The Proposed Solution shall govern user access to API that they subscribe yes yes

67 The Proposed Solution shall provide a management UI that shows API monetization related contents yes yes

68 The Proposed Solution shall secure and mediate the following traffic between: yes

69 a) Clients and backend yes yes 70 b) The TM APIs and the developers, users, partners yes yes

71

The Proposed Solution shall provide an environment where developer can simulate and test their apps integration with the API platform for free within certain credit limit and accessibility of certain time frame. yes yes

72

The Proposed Solution shall provide the service usage of API service transactions to be measured and controlled at API management layer. The metering shall be in the form of number of page views, number of minutes call, number of SMS, transaction value for payment gateway yes

yes it can be supported. if there is any customization for how the usage report

should look like then we can do it.

73

The Proposed Solution shall provide platform for users to enquire about TM API services via emails, telephones, social media and social network. yes

yes. we have ticketing module for partner or developer to send their issue

and raise a ticket. then it can be entertained by TM staff accordingly.

74 The Proposed Solution shall provide a developer portal with the following purposes: yes

75 a) To attract and engage app developers yes yes. this is default feature through our self service KYC enabled partner portal.

76 b) To explore and test APIs yes yes. this is default feature through our self service KYC enabled partner portal.

77 c) To purchase and start using the services yes yes. this is default feature through our self service KYC enabled partner portal.

78 d) To publish the services yes

we need more clarification for this in terms of what does developer publish

service means.

79

The Proposed Solution shall support all common types of Operating System platform (e.g. Android, Windows, IOS, Ubuntu) and devices (e.g. desktop, tablets, smartphones, laptops) yes yes

80 The Proposed Solution shall list out API services so the developer has option to pick and choose. yes yes

81 The Proposed Solution shall provide the User Access Management to do the followings: yes

82

a) Add and manage users by providing the core services necessary for secure registration and log in (e.g. Oauth 2.0-‐compliant client authentication) yes yes. we are providing 2FA based login.

83 b) Login via Social Network connections (Twitter, G+, Facebook, Email or Phone number) yes not needed as mentioned above.

84 c) Profile Management (reset password) yes yes

85 The Proposed Solution shall comply to TM's layout branding. yes

yes. This will require some customization that we will do at time of

execution and delivery of project.

86 The Proposed Solution shall display T&C as a guideline to the developers in using TM APIs. yes yes

87

The Proposed Solution shall provide an environment where developer can simulate and test their apps integration with the API platform for free within certain credit limit and accessibility of certain time frame. yes yes

88

The Proposed Solution shall enable developers to test drive and explore the API services using the API console prior to having full integration with the API services. yes yes

89 The Proposed Solution shall display FAQ or guideline for developers. yes

not supported right now.however it can be added as per what is needed? the knowledge bank can be built over time and exposed as FAQ or guidelines. We also provide that there should be videos for partners to quick learn how to use the platform. We can assist in making

these videos.

90 The Proposed Solution shall provide developers with SDK/plugin download. yes yes

91 The Proposed Solution shall allow the first time Developer yes

to register with the following process flow:

92 a) By filling in the business information (e.g. Company Name, Business Registration Number, Company Address) yes Yes

93 b) Uploading the business document (e.g. SSM Document, Form 49) yes Yes

94 c) Pending upon approval yes Yes 95 d) Receive notification yes Yes

96

The Proposed Solution shall allow the activation of application into production environment to be controlled by System Administrator. yes yes

97

The Proposed Solution shall validate the developer user profile (e.g. Bad debt) and prompt notification to System Administrator on the status. This shall only apply for the first time subscriber of the API service. yes Yes

98

During activations, the Proposed Solution shall allow the following information to be defined by System Administrator: yes

99 a) Contract term yes yes 100 b) User Segment (e.g. SME/Enterprise/Government/G&W) yes yes 101 c) Sub user segment (e.g. S10, S20, E10) yes yes 102 d) Profit Centre yes yes 103 e) Pricing (not applicable if standard subscription) yes yes 104 f) Charging mode (e.g. Monthly/Quarterly/Yearly) yes yes 105 g) Account Manager details (e.g. Name & Email) yes yes

106 The Proposed Solution shall allow to add any additional information related to activation process. yes

we need to know more details on additional details.

107 The Proposed Solution shall allow developers to perform performance tracking (e.g. errors and usage) relating to all yes yes

or specific sets of their apps and APIs.

108

The Proposed Solution shall provide developer with ability to view their details API subscriptions (e.g. usage, subscribed plans, invoices, outstanding statements, payments made). yes yes

109

The Proposed Solution shall display showcase on latest news (e.g. API developments, social media conversations, discussion forums and blogs). yes

for enterprise rollout we do not suggest to have this. however if needed we can expose APis to share the newly added

APIs to public.

110

The Proposed Solution shall provide RESTful framework for sending push notifications to apps, giving full control over which app users to send notifications. yes Yes

111

The Proposed Solution shall have the ability to send messages to devices, users, or groups that have specific characteristics and locations. yes

yes. right now devices, users are supported. location or some criteria can

be added to filter it now.

112

The Proposed Solution shall provide the service usage of API service transactions to be measured and controlled at API management layer. The metering shall be in the form of number of page views, number of minutes call, number of SMS, transaction value (payment gateway). yes yes

113

The Proposed Solution shall prorate and charge accordance to the usage (e.g. Monthly, Quarterly, Half Yearly and Annually) and shall integrate with TM prepaid engine. yes yes

114

The Proposed Solution shall provide all type of charging (e.g. monthly, charging on usage by minutes, charging on transaction based and One Time Charge). yes yes

115 The Proposed Solution shall support Debit or Credit yes Yes

treatment with descriptions.

116 The Proposed Solution shall configure and store international pricing. yes

this can be supported with customization.

117

The Proposed Solution shall capture billing when there is delay in intermediation CDR record retrieved from TM backend platform yes yes

118 The Proposed Solution shall segment the revenue flow to respective unit or division in TM. yes

yes it can be done but needs some customization.

119 The Proposed Solution shall integrate with TM Revenue Management platform for journaling purpose. yes


120

The Proposed Solution shall provide online payment method for developer to be able to pay the API subscription and service usage (e.g. Online Banking, Credit or Debit Card) yes


121

The Proposed Solution shall capture payment made by user at any TM point branches to be reflected in API Portal. yes

yes. TM point branch manager can login to Partner Portal Admin and fill the payment details. It can be automated

122

The Proposed Solution shall impose penalty (e.g. charging un-‐fulfilled remainder contract term) to user due to early termination yes yes

123 The Proposed Solution shall follow TM's standard billing format and service description for each charging element. yes yes

124 The Proposed Solution shall provide Billing complaint via online ticketing creation. yes yes

125 The Proposed Solution shall provide Invoice and payment notification via email and SMS. yes yes

126

The Proposed Solution shall provide ability to breakdown and calculate the revenue sharing model and the cost (amount to be defined by TM) associated with TM partner yes yes

for selected API bundles.

127 The Proposed Solution shall be GST Compliance. yes yes

128

The Proposed Solution shall provide the predefined packaging according to TM's API business model positioning where it is able to support basic options and rules as follows: yes yes

129 a) Monthly Fee for selected API bundles & Service Type yes yes

130 b) One Time Charge for selected API bundles & Service Type yes yes

131 c) Tiering, freemium and pay per use models yes yes

132 d) Ability to capture transaction value (e.g. specifically for payment gateway API service) yes yes

133 e) Ability for unit level charging: Up to 4 decimal value capability (e.g.: RM0.0002/Minute, RM0.0003/hit) yes yes

134

f) Pricing (recurring and one-‐time charge) may vary for each developers and TM admin shall customize those for each of them. yes yes

135 g) Option for custom pricing uest by developers shall be made available yes yes

136 The Proposed Solution shall have the flexibility to support any business models to be implemented by TM. yes yes

137 The Proposed Solution shall support free allocations (e.g. free minutes, free transaction (hit), waiver). yes yes

138

The Proposed Solution shall support API bundles and Service Type (e.g. pattern by number of transactions, service usage, usage capacity). yes yes

139

The Proposed Solution shall provide Platform performance and reliability tracking (e.g. traffic response time, errors, dataexchange). SLA threshold to be defined to ensure exceptional performance of the platform yes yes

140

The Proposed Solution shall monitor application errors and crashes by application versions, platforms, devices, and OS versions. The Proposed Solution shall isolate root causes of errors and crashes and API performance issues through information captured in crash logs and API call logs. yes

errors and crashes are supported from service guard to resources.

constant 24x7 monitoring is done of the resource to ensure they are up and run and now slow in response.

141

The Proposed Solution shall capture geolocation data from users’ GPS-‐enabled devices and associate with places, activities, events, people and devices. yes

this does not apply. please explain more on what is needed under this feature.

142

The Proposed Solution shall display user location, activity streams that enable publishing of user actions, comments, activities and tweets. yes

this does not apply. please explain more on what is needed under this feature.

143

The Proposed Solution shall notify users (e.g. administrators and account managers) on the traffic patterns for changes yes yes

144 API traffic, response times and error rates by daily and monthly. yes yes

145

The Proposed Solution shall perform credit management treatment (e.g. suspension of service) either by human triggered (TM administrator/Account Managers) or system automated via integration with TM systems. yes yes

146

The Proposed Solution shall provide ability for TM administrator to define and change credit limit for the API bundles and yes yes

147 service type use in both sandbox and production environments. yes yes

148 The Proposed Solution shall detect any abnormal usage patterns. yes yes

149 The Proposed Solution shall provide fault escalation via online ticketing. yes yes

150

The Proposed Solution shall provide ability to isolate the fault whether it occurs at user application, TM API management, gateway, middleware or backend system. yes yes

151

The Proposed Solution shall provide ability to conduct connectivity testing from developer applications towards the TM API Management Platform and the backend system. yes yes

152

The tenderer shall provide consultancy and advice to TM on the integration and best practices from existing operation yes yes

153

The Proposed Solution shall send the related information (e.g. user profile, package, pricing and usage) to TM systems to generate the invoice for the developers. The invoice produced shall then be sent to the developers via email and shall be hosted at portal. yes yes

154 The Proposed Solution shall provide integration with TM systems to host all user profiling and validation. yes yes

155 The Proposed Solution shall integrate with any TM systems services for monetisation purpose. yes yes

156

The Proposed Solution shall generate detail method level Smart Docs and providing developers with comprehensive information and guideline. yes yes

157 Partner Cert Based Auth (Test and Production) no yes 158 Token Based Auth (Test and Production) no yes 159 Ip Based Auth (Test and Production) no yes

160 Online Soap support (Test and Production) no yes 161 HTTP Web Form support (Test and Production) no yes 162 Online WADL support (Test and Production) no yes 163 Local WSDL support (Test and Production) no yes 164 ISO-‐8583 Support (Test and Production) no yes 165 Publish Web Service Without Transform no yes

166 Versioning (can create multiple versions and can be managed) no yes

167 Time Restriction no yes 168 Day Restriction no yes 169 Volume Restriction no yes 170 Transaction Billing no yes 171 Debugging no yes

172 JOSN/XML encryption/Decryption and Signing/verify (partner-‐SG) no yes

173 JOSN/XML encryption/Decryption and Signing/verify (SG-‐resource) no yes

174 JOSN/XML encryption/Decryption and Signing/verify (partner-‐sg-‐resource) no yes

175 Certificate and key management no yes 176 Monitoring (website and ip) no yes 177 Forget Password no yes 178 Visibility of apis, api params, and class params no yes 179 changing names of apis, api params, and class params no yes 180 assign default value to api params, and class params no yes 181 Logging no yes 182 Real time monitoring no yes 183 Reports no yes

184 WSDL and WADL for each resource type. no yes 185 can change (Resource Info runtime eg. Wsdl url change) no yes

SrNo. Features CaaS SG Biller 186 Automated or Manual manual Automated 187 various price package yes yes 188 Invoice provides formatted bill information yes yes 189 Test Credit Point yes yes 190 Number Rental Price yes yes 191 Pricing Plan yes yes 192 Service Package yes yes 193 Price plan query yes yes 194 Rating yes yes 195 Credit Control yes yes 196 Periodic Bill Process yes yes 197 Flat Price yes yes 198 Price package selection yes yes 199 Price package customization yes yes 200 Public type yes yes 201 Customized type yes yes 202 Discount yes yes 203 Time schema yes yes 204 Service Type yes yes 205 Document Security (digital signature) no yes 206 Document Security (Encrypted with Password) no yes 207 Promotion Code based Discounted no yes 208 Tiered And slabbed billing no yes 209 Commission billing no yes

210 Alert on time based for payment, usage thresholds no yes 211 Bills (PDF) to have graphical charts no yes

212 Exposing Billing APIs to partners and 3rd party systems no yes

213 usage alert no yes 214 Grace Credits with Additional charge no yes

215 Credit Points Redeeming facility like loyalty credit card program no yes

Technology

Mulesoft vs Service Guard