[BUG] Error while parsing Subdefinition about wsdl-tsclient HOT 13 CLOSED

yeah that is similar to what I was planning I was just hoping to have it automatically generated is all.

Also rather then exposing each individual service I was hoping it would auto generate pass through functions so I could just have one top level client and call all functions and have them simply passed through to the needed service/resource path.

from wsdl-tsclient.

Hi,
I tried to parse that wsdl file and it works, when I increased limit of max maxRecursiveDefinitionName to 85. It happens when there are a lot of definitions with same name. Then new option maxRecursiveDefinitionName will be available in next release (currently available in master branch).

from wsdl-tsclient.

thanks is there an ETA on when this fix will be released in a tagged version?

from wsdl-tsclient.

@starsoccer new version 1.2.0 is released https://github.com/dderevjanik/wsdl-tsclient/releases/tag/1.2.0

Update your package and pass --maxRecursiveDefinitionName=90 argument to CLI, like wsdl-tsclient ./Human_Resources.wsdl --maxRecursiveDefinitionName=90 -o ./generated

from wsdl-tsclient.

thanks that seems to have worked. I had to bump it to 180 though as some other files were having issues.

On an unrelated note it would be nice if there was a way to merge multiple wsdl files. In the case of workday there are 10+ different wsdl files and ideally I could just make one client with a shared authentication and endpoint rather then have to do so for each resource. But I can make another issue for that if you think its an idea worth exploring.

from wsdl-tsclient.

I see your point, but IMO it isn't good idea to merge multiple files.... instead of merging several wsdl files into one, you can generate several wsdl clients at once (wsdl-tsclient ./path/to/*.wsdl -o ./generated) and then in your code create one access point to your APIs (Google is doing same thing with google-api, where you initialize one class with several APIs at once and shared auth).

// api/commnuityworkday.ts
import soap from "soap";
import { createClientAsync as createHumanResourceClient, HumanResourceClient } from "../generated/humanresources";
import { createClientAsync as createCompanyServiceClient, CompanyServiceClient } from "../generated/companyservice";
import { createClientAsync as createFileShareClient, FileshareClient } from "../generated/fileshare";

interface CommunityWorkdayAuth {
    username: string;
    password: string;
}

class CommunityWorkdayAPI {
  
  private _humanResourceClient: HumanResourceClient;
  private _companyServiceClient: CompanyServiceClient;
  private _fileshareClient: FileshareClient;

  async init(auth: CommunityWorkdayAuth) {
      const basicAuth = new soap.BasicAuthSecurity(auth.username, auth.password);
      
      this._humanResourceClient = createHumanResourceClient("./resources/Human_Resources.wsdl");
      this._humanResourceClient.setSecurity(basicAuth);
      
      this._companyServiceClient = createCompanyServiceClient("./resources/CompanyService.wsdl");
      this._companyServiceClient.setSecurity(basicAuth);
      
      this._fileshareClient = createFileShareClient("./resources/FileShare.wsdl");
      this._fileshareClient.setSecurity(basicAuth);
  }

  humanResource() {
      return this._humanResourceClient;
  }

  company() {
      return this._companyServiceClient;
  }

  fileShare() {
      return this._fileshareClient;
  }

}

Then you can use it as module in your project (I'm used to create NPM library from code above to avoid generating client everytime).

// main.ts
const communityWorkday = new CommunityWorkdayAPI();
await communityWorkday.init({ username: "admin", password: "adminpwd" });

await communityWorkday.fileShare().sendFileAsync({ path: "path/to/file" });

I hope this may help you

from wsdl-tsclient.

There also seems to be an issue with some of the auto generated function and parameter names that include a dash which isnt allowed and causes typings to break. I think a simple fix for this is to just replace all - with a underscore instead

from wsdl-tsclient.

Sure, I forget about those... We already have changeCase function, which replaces all ., so we can extend that...

from wsdl-tsclient.

It may be worth using a package that checks to ensure the string used is a valid java script variable name: https://www.npmjs.com/search?q=valid%20variable%20name

from wsdl-tsclient.

Yeah, it would be great to find good library for making sure the variable name is valid javascript varname.

Please, is your issue with - similar to #18 ?
I just published dev version npm i wsdl-tsclient@dev, so you could try if the issue with wrong property names persists.

from wsdl-tsclient.

Yes I think its similar. Sadly the dev version doesnt fully resolve the issue. I still have cases like Put_User-Based_Security_Group_AssignmentAsync that is invalid

from wsdl-tsclient.

Oh, now I see similar problem. I only fixed definitions, not Ports nor Services. I'm going to fix it.

Besides that, I created PR to make sure all generated wsdl-tsclient are compile-time valid #19

from wsdl-tsclient.

Awesome well if you need me to try anything else just let me know. Otherwise I think atleast for now this can be closed

from wsdl-tsclient.