Best approach to implement custom SSO in Mendix using SOAP (.asmx) API and Best approach to upload CSV, read data, display in table and export to Excel in Mendix (without third-party modules)

0
```htmlQuestionI'm working on custom SSO login for a Mendix application using an external SOAP (.asmx) API. The flow I need is: user enters username → call external API → validate user → create or update Mendix user → log in.ContextI've explored three approaches:Consumed Web Service (WSDL generation is failing)REST call with manual SOAP XMLImport Mapping for XML parsingThe API returns user details (displayName, department, roles) in XML format and requires only a username—no password.Mendix Version: 10.24.11What I NeedI'm looking for guidance on:Which approach works best for production SOAP SSO integration in Mendix?When to use Consumed Web Services vs. REST with manual XML vs. Import Mapping?Any recommended architecture or alternative solutions for this scenario?```Also i want to know regarding I need help implementing CSV file handling in Mendix without third-party marketplace modules. Users need to upload a CSV, view it in a grid, and download it as an Excel file using only native Mendix features.ContextI've identified the basic workflow:Read CSV file content as a stringParse rows and columns manuallyStore data in a Non-Persistent entityDisplay in a Data GridGenerate Excel output using a document templateWhat I'm Unsure AboutI have questions on:What's the recommended approach for reading and parsing CSV in Mendix?Is manual string parsing the right method, or is there a better option?What limitations exist with this approach (like handling commas within values)?Is there a more efficient or scalable way using only native capabilities?What I NeedGuidance on the recommended architecture and approach for this use case without external modules.
asked
1 answers
0

For the SOAP SSO use case, my recommendation would be:

  • Use Consumed Web Service if the WSDL can be imported successfully. This is the most maintainable and Mendix-native approach.
  • If the WSDL is not compatible or cannot be generated, use a REST Call with a manually constructed SOAP XML request and parse the response using an Import Mapping.
  • After validation, create/update the Mendix user and perform a custom sign-in flow.

Personally, I would avoid manually parsing XML strings unless absolutely necessary. Import Mappings are much easier to maintain and less error-prone.

For the CSV requirement without third-party modules:

  • Upload the file using a FileDocument.
  • Read the content in a Java action or microflow.
  • Parse the rows and map them to a Non-Persistent or Persistable entity.
  • Display the data in a Data Grid or Data Grid 2.

One thing to keep in mind is that manual CSV parsing can become complex when handling:

  • commas inside quoted values
  • escaped quotes
  • multiline fields

So if you go with manual parsing, make sure your CSV format is well-defined and controlled.

For exporting, I would recommend generating an Excel file directly rather than using a document template, since document templates are intended for PDF/DOC-style output rather than true Excel workbooks.

Kindly mark this as the accepted answer if it helps.

answered