Consuming a SOAP API with unique Authentication requirements
Application Type
Mobile
Service Studio Version
11.50.12 (Build 47993)
Platform Version
11.13.0 (Build 31107)

First, thank you for this communities continued help, it's a one of a kind community that I am very thankful for; very well done.

  • PROBLEM: Can't authenticate a SOAP API.
  • AUTHENTICATION REQUIREMENTS: User: <username>     Password: <password>   Company Key: <key>

I am able to consume the XML file for the SOAP API downloaded to my computer and I see all the "Methods"(that's what they refer to them as).  In the methods within the API, each one requires a Login, Password, and CompanyKey parameter; see below:

  • Common Parameters:

Login (string) *required

        The authorized system login of the user.

Password (string) *required

         The corresponding password of the system login.

CompanyKey (string) *required

SOLUTION (HELP):

I thought you needed to provide this information as a authentication to enable the API tunnel information travels through per say.  But looking at the below photo of the consumed API, I noticed there is an input parameter for the authentication.  So maybe however you send the parameters for the data you need, you just include with that the above authentication parameters first.  I guess I was thinking about it more from a Network type standpoint, where you need the authentication to establish the connection to start off with.  Ok, so I will figure out how to send the parameters of what you need for example, if you input a name and hit search, how it sends that information to the API requesting the data.  If anyone has any resources that could be helpful on how to do this, that would be very much appreciated!

Next, we have a Claims Management System and this API connects to that from an app we are building.  Every user for the CMS (Claims Management System) will have a user account for their app that will only allow them to see the same data that is in the CMS.  In other words, an adjuster can't see another adjusters claims.  However, the CMS will only provide us with one login for the API thus it has to be an admin able to see all claims.   I connected the users via Azure AD and if anyone has any advice on how to go about restricting the users data in the same way it would be if they were logging into the CMS directly vs accessing the data via the app, that would be really helpful.   Another example of what I mean, if the user is Dan and he does a search, he would only be able to see "Dan's" files.  However, if the search goes out the API via an admin credentials, it will return all users files rather than only Dan's. So in the app I need to restrict what files the app shows to Dan out of the data that was returned via the API.  


If anyone has any documentation or examples that would be helpful.

I assume I will use Role restriction or something not sure...


soapapi.png

mvp_badge
MVP
Solution


No problem!

You might have to look into some sort of caching mechanism if you need users to look at the information while their device is offline. You could consider storing the list of retrieved files/documents in a Local Entity - this would allow you to save the information retrieved from the API on the user device, increasing performance since it reduces API calls, and would allow the user to still view old data from the last call in case they go offline. Essentially, every time the user is online and consults the API data, you can update your Local Entity with fresh data, and if the user goes offline, you can just skip the API call.

This is all very dependant on the usecase of your mobile app, and you should avoid storing the content of every file/document - if the size of your Local Entities gets too large, performance might be impacted.

Let us know of any questions you might have.

Hi Cody,


There a plenty of information in OutSystems Foruns

IN the past I implemented in a several projetcs, using authetication through Header.

Remember you will need the WSDL contract to consume from OS.

Maybe this can help you out.

https://success.outsystems.com/Documentation/11/Extensibility_and_Integration/SOAP/Consuming_SOAP_Web_Services/Use_Advanced_Extensibility

https://www.outsystems.com/forums/discussion/48165/exposing-soap-service-requiring-authentication/

https://www.outsystems.com/forge/component-overview/5322/soap-extensibility

Regards

mvp_badge
MVP

Hello Cody,

Reading through your thoughts, it looks like your questions are very much related to the API in question, namely:

 - how to perform searches with the API;

 - how to restrict information based on the user;

Thinking on it, I believe you could somehow restrict the information if you're able to associate the currently logged-in OutSystems user with the information that is being received from the API. So essentially, if you know Dan is logged in, and the API search will return all files, you could use something like a ListFilter Action in your logic and filter for all of Dan's files (if you can identify them from the API's output). This is not very ideal, however. You mention that the API allows for searching - is it be possible that one of its parameters can allow you to search for only the files of a specific user? This way, you'd restrict the data with more ease.

Sorry for being a little too theoretical. Is this a public API that other community members can invoke, or is it something private? If this is something that we can all connect to, we might be able to offer more specific help.

Thank you Afonso and appreciate that great advice!

I was able to figure out the authentication, there was a long, password and company key structure under the variable when I consumed it so just had to send the data to those variables inclusive of the data I needed the API to return. 

The idea you have on the filtering it is exactly what I'm thinking.

It is a private API.

One thing I ran into though, the API data isn't capable of being accessed offline. 

Just a bunch I have to think about. 

I'm more of a business man than a developer really. :)

I'm going to reply back with any other areas that jump out on this API, I'm working on it tonight and tomorrow.

Thanks again!

mvp_badge
MVP
Solution


No problem!

You might have to look into some sort of caching mechanism if you need users to look at the information while their device is offline. You could consider storing the list of retrieved files/documents in a Local Entity - this would allow you to save the information retrieved from the API on the user device, increasing performance since it reduces API calls, and would allow the user to still view old data from the last call in case they go offline. Essentially, every time the user is online and consults the API data, you can update your Local Entity with fresh data, and if the user goes offline, you can just skip the API call.

This is all very dependant on the usecase of your mobile app, and you should avoid storing the content of every file/document - if the size of your Local Entities gets too large, performance might be impacted.

Let us know of any questions you might have.

Thank you Alfonso - is there any template type documents you use to create your data management patterns that you wouldn't mind sharing?  Most data would be non-updated data with just metadata within that data that would need to be real-time as files progress forward.  I was reading about cold cache I think it was.  Right now I'm just trying to conclude getting data in general from the API and over to storage.  I do need full offline use and on a "per user" basis the data is not a lot.  It's only a lot of data when looking at it as a whole.  Say there is 100+ users each with around 10-30 claims at any given moment.  The 10-30 claims is all we would need to be concerned with per device/phone and the binary data for the claim could be retained on the server to be called when needed by the user.  Most binary data will be going the opposite way around, pictures taken by field inspector that would be going out via API.

mvp_badge
MVP

I'd say that all you need to implement for your offline usecases would be to store the claim list of that specific user, along with whatever associated metadata you want to present alongside it within a set of Local Entities. If the user tries to visit the detail page of that claim, you could display the claim data you stored, and block out the binary data with a notification for the user to go online. Depending on how often you need to update this binary data and how large it is on average, you could also just store it as well: 10-30 files shouldn't pose a performance problem if they're reasonably sized.

There's not really a one-size-fits-all solution for these cases because it's going to be very reliant on the sort of operations you want the user to be able to perform when he's offline - being able to consult data is simple enough, but allowing him to queue up actions which then get sent to the server when the user goes online can be more difficult (resolving conflicts can be a particularly tricky requirement, for instance).

Once you have the data from the API figured out, this article is a very good overview on the different data sync patterns you can consider for your usecases - reading over what you shared, I think Read-Only Data would be enough if you don't plan on allowing users to view the binary data while offline, and Read-Only Data Optimized could be used if you require that initial binary data to be stored on the device for offline viewing.

Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.