XML::C...eration(3pm)

πŸ“¦
version 3.28 Β· 2 versions
  • 3.28 Β· debian bookworm, debian trixie, ubuntu noble, ubuntu resolute, ubuntu stonking (latest)
  • 3.27 Β· ubuntu jammy
, in debian bookworm, debian trixie, ubuntu noble, ubuntu resolute, ubuntu stonking

πŸ’– NAME πŸ’–

XML::Compile::SOAP11::Operation β€” defines a SOAP11 interaction ✨

okay so real talk, this page lives in the <rainbow>XML::C...eration(3pm)</rainbow> manual (User Contributed Perl Documentation, the truncated-title situation is iconic honestly), and it's all about one single SOAP11 interaction. slay.


🌸 INHERITANCE 🌸

the family tree, periodt:

 XML::Compile::SOAP11::Operation
   is a XML::Compile::SOAP::Operation

✨ SYNOPSIS ✨

look at this lil snippet, it's giving "made by XML::Compile::WSDL*":

# object created by XML::Compile::WSDL*
my $op = $wsdl->operation('GetStockPrices');
$op->explain($wsdl, PERL => 'INPUT', recurse => 1);

πŸ¦‹ DESCRIPTION πŸ¦‹

Objects of this type define one possible SOAP11 interaction β€” either client side or server side. pick your main character energy πŸ’…

Extends "DESCRIPTION" in XML::Compile::SOAP::Operation.


πŸ’œ METHODS πŸ’œ

Extends "METHODS" in XML::Compile::SOAP::Operation.

πŸŽ€ Constructors πŸŽ€

Extends "Constructors" in XML::Compile::SOAP::Operation.

XML::Compile::SOAP11::Operation->new(%options)

"input_def", "output_def" and "fault_def" are HASHes which contain the input and output message header, body and fault-header definitions in WSDL1.1 style. no cap, that's literally what they are 🫢

here's the whole options table, and bestie I am NOT skipping a single line:

 -Option     --Defined in                   --Default
  action       XML::Compile::SOAP::Operation  undef
  endpoints    XML::Compile::SOAP::Operation  []
  fault_def                                   <undef>
  input_def                                   <undef>
  kind         XML::Compile::SOAP::Operation  <required>
  name         XML::Compile::SOAP::Operation  <required>
  output_def                                  <undef>
  schemas      XML::Compile::SOAP::Operation  <required>
  server_type  XML::Compile::SOAP::Operation  undef
  style                                       'document'
  transport    XML::Compile::SOAP::Operation  'HTTP'

and now the vibe check on each one:

  • action => STRING
  • endpoints => ADDRESS|ARRAY
  • fault_def => HASH
  • input_def => HASH
  • kind => 'one-way'|...
  • name => STRING
  • output_def => HASH
  • schemas => XML::Compile::Cache
  • server_type => NAME
  • style => 'document'|'rpc'
  • transport => URI|'HTTP'

🌈 Accessors 🌈

Extends "Accessors" in XML::Compile::SOAP::Operation.

  • $obj->bindingName() β€” Inherited, see "Accessors" in XML::Compile::SOAP::Operation
  • $obj->clientClass() β€” Inherited, see "Accessors" in XML::Compile::SOAP::Operation
  • $obj->endPoints() β€” Inherited, see "Accessors" in XML::Compile::SOAP::Operation
  • $obj->kind() β€” Inherited, see "Accessors" in XML::Compile::SOAP::Operation
  • $obj->longName() β€” Inherited, see "Accessors" in XML::Compile::SOAP::Operation
  • $obj->name() β€” Inherited, see "Accessors" in XML::Compile::SOAP::Operation
  • $obj->portName() β€” Inherited, see "Accessors" in XML::Compile::SOAP::Operation
  • $obj->schemas() β€” Inherited, see "Accessors" in XML::Compile::SOAP::Operation
  • $obj->serverClass() β€” Inherited, see "Accessors" in XML::Compile::SOAP::Operation
  • $obj->serviceName() β€” Inherited, see "Accessors" in XML::Compile::SOAP::Operation
  • $obj->soapAction() β€” Inherited, see "Accessors" in XML::Compile::SOAP::Operation
  • $obj->style()
  • $obj->version() β€” Inherited, see "Accessors" in XML::Compile::SOAP::Operation
  • $obj->wsaAction('INPUT'|'OUTPUT') β€” Inherited, see "Accessors" in XML::Compile::SOAP::Operation
yes style() really has no note next to it. that's just how it is. we don't make the rules πŸ’€

πŸ’… Modify πŸ’…

Operations are often modified by SOAP extensions. See XML::Compile::SOAP::WSA, for instance. Also demonstrated in the FAQ, XML::Compile::SOAP::FAQ.

$obj->addHeader( <'INPUT'|'OUTPUT'|'FAULT'>, $label, $element, %options )

Add a header definitions. Many protocols on top of SOAP, like WSS, add headers to the operations which are not specified in the WSDL.

[2.31] When you add a header with same $label again, it will get silently ignored unless the $element type differs. An $element is either a full type or a [3.00] prefixed type. lowkey sneaky but okay.

 -Option        --Default
  destination     undef
  mustUnderstand  undef
  • destination => ROLE β€” [2.33] adds the destination attribute.
  • mustUnderstand => BOOLEAN β€” [2.33] adds the mustUnderstand attribute.

🧚 Handlers 🧚

Extends "Handlers" in XML::Compile::SOAP::Operation.

$obj->compileClient(%options)

Returns one CODE reference which handles the processing for this operation. Options "transporter", "transport_hook", and "endpoint" are passed to compileTransporter().

You pass that CODE reference an input message of the correct type, as pure Perl HASH structure. An 'request-response' operation will return then answer, or "undef" in case of failure. An 'one-way' operation with return "undef" in case of failure, and a true value when successful.

You cannot pass options for XML::Compile::Schema::compile(), like "<sloppy_integers =" 0>>, hooks or typemaps this way. Provide these to the "::WSDL" or other "::Cache" object which defines the types, via "new" option "opts_rw" and friends.

fr fr, don't try to sneak those in here, it will NOT work πŸ™ˆ

$obj->compileHandler(%options)

Prepare the routines which will decode the request and encode the answer, as will be run on the server. The XML::Compile::SOAP::Server will connect these. All %options will get passed to XML::Compile::SOAP11::Server::compileHandler()

 -Option  --Default
  callback  <required>
  selector  <from input def>
  • callback => CODE
  • selector => CODE β€” Determines whether the handler belongs to a received message.

$obj->compileTransporter(%options)

Inherited, see "Handlers" in XML::Compile::SOAP::Operation

⭐ Helpers ⭐

Extends "Helpers" in XML::Compile::SOAP::Operation.

$obj->explain($wsdl, $format, $direction, %options)

[since 2.13]

Dump an annotated structure showing how the operation works, helping developers to understand the schema. The $format must be string "PERL". ($format "XML" is not yet supported)

When the $direction is string "INPUT", it will return the message which the client sends to the server (input for the server). The "OUTPUT" message is sent as response by the server.

All %options besides those described here are passed to XML::Compile::Schema::template(), when "recurse" is enabled.

 -Option     --Default
  recurse      <false>
  skip_header  <false>
  • recurse => BOOLEAN β€” Append the templates of all the part structures.
  • skip_header => BOOLEAN

$obj->parsedWSDL(%options)

Inherited, see "Helpers" in XML::Compile::SOAP::Operation


πŸ”₯ SEE ALSO πŸ”₯

This module is part of XML-Compile-SOAP distribution version 3.28, built on August 01, 2022. Website: http://perl.overmeer.net/CPAN/ 🌐


πŸ‘‘ LICENSE πŸ‘‘

Copyrights 2007-2022 by [Mark Overmeer <markov@cpan.org>]. For other contributors see ChangeLog.

This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself. See http://dev.perl.org/licenses/


and that's the whole page bestie 🫢 this was perl v5.34.0, dated 2022-08-04, and yes the footer really does still say XML::C...eration(3pm) β€” the truncated title stays, it's part of the lore πŸ’–βœ¨
πŸ“¦ where this page comes from