Kicksaw-Consulting / simple-mockforce

A companion package for simple-salesforce that enables the testing of code that interacts with Salesforce's API
MIT License
15 stars 7 forks source link

XML for virtual organization #17

Open Safintim opened 2 years ago

Safintim commented 2 years ago

I found an article that talks about future plans. Did I understand correctly that there are plans to use XML as object validation? If so, that's a great idea. I would like to analyze it and maybe suggest something.

@brno32 How can you get XML for your organization? I searched and couldn't find it.

kicksaw article

brno32 commented 2 years ago

Yes it's my long-term goal to use an org's definition to provision the virtual salesforce org, but it's a huge task and we haven't started on it yet.

You could use the metadata api to download the source for your org, or use sfdx to retrieve the XML definition of a lot of Salesforce resources, and it would be cool if mockforce read either of those.

Safintim commented 2 years ago

I suggest start with a simpler format - json. Implement simple checks on the data type nullable, required.

Do you have any ideas yet? I think straightforward checks would be difficult to support (I mean, do JSON, xml analysis every time).

I think in this situation code generation is appropriate. datamodel-code-generator (generate pydantic model for validation) provides such functionality. For example we could analyze JSON, XML - prepare json or yaml for datamodel-code-generator, generate models and do validation based on them. There are a lot of questions here.

Did some research. Also Salesforce REST API from v54.0 in beta mode generates openapi documentation. I tried it, the file for the test organization is about 18 MB. Unfortunately, there is no data there whether the field is mandatory whether it can be null. datamodel-code-generator generated for 38 thousand lines of python code :)

brno32 commented 2 years ago

Oh sure we'd convert the XML to JSON at runtime, but what I mean is Salesforce can give you an org definition in xml format using the metadata or soap api. From that xml, we could read the schema and use that to build a virtual salesforce org that more closely resembles the org in question.

It'd be cool if we could use the openapi documentation, but I don't think it would work for our needs as you said. I think using sfdx or the metadata api already wrapped in simple-salesforce would work better. From there, we could get the xml schema of all the objects, convert to json with xml2dict, and then write code to more closely mimic the behavior of the real Salesforce API like you suggested: check for required fields, validate data types, check field and object names are correct, etc

I hadn't thought of using a code generation tool, but I'm definitely interested in that idea!

Here's a trailhead for sfdx https://trailhead.salesforce.com/content/learn/modules/sfdx_app_dev