New Request Ticket_CancelDocument missing - how to contribute

[nikhildeshmukh]

Hi @DerMika
Ticket_CancelDocument is missing in the library.
Can you please let us know what steps we should follow to add this in this library.
We will like to contribute this for the library
Thanks

[DerMika]

Hi, that would be wonderful!

I wrote a quick explanation of how to add a new message to the library in this comment.

That comment is about Service_IntegratedPricing but the steps to add a new message are the same, except that you have to use the appropriate class names for the new message. You can look at other already implemented messages to see how it's done.

If you have any questions or run into any problems, I'd be happy to help.

[DerMika]

Also, It's OK to not implement all possible features of a message, as long as the request options class is written in such a way that missing features can be added later on without breaking backwards compatibility.

But of course, it's even better if you implement all possible features for which there is an example in the Amadeus Web Services extranet guide.

[bimusiek]

When I was first implementing new messages I just went to commit where @DerMika implemented one endpoint and followed his steps.

Last time I have implemented FOP_ValidateFOP (which is really simple as I did not implement all the features) I basically did same steps @DerMika did.

You can take a look at the PR here

[nikhildeshmukh]

Hi @DerMika @bimusiek
I am having some issues on the same.
I was been following the steps provided by you.
i have some questions on general

whenever when we are creating new request how to identify which paramaters will be dynamic and how to pass those.
Sorry if these are some silly questions but i am new over soap development.

[DerMika]

So, in Amadeus\Client, you should have added a method to call the new message analogous to how other messages were implemented.

For example, let's look at the implementation of Ticket_CreateTSTFromPricing: the method is called Amadeus\Client::ticketCreateTSTFromPricing().

Each message call in Amadeus\Client will receive 2 parameters, the first of which is an instance of Amadeus\Client\RequestOptions\Base. For the example message Ticket_CreateTSTFromPricing, it is called Amadeus\Client\RequestOptions\TicketCreateTstFromPricingOptions. This class contains all the options that users can provide when calling ticketCreateTSTFromPricing.

This Request Options object will be used to generate a message Amadeus\Client\Struct\Ticket\CreateTSTFromPricing. Amadeus\Client\Struct\Ticket\CreateTSTFromPricingis the actual PHP object that will be converted to an XML message by PHP's \SoapClient.

You need a Request Converter Amadeus\Client\RequestCreator\Converter\Ticket\CreateTSTFromPricingConv (the names of the files are important because they depend on the name of the message that was called) to convert the Request Options into a message structure.

Usually, the Converter does nothing more than handing the Request Options object to the Structure object, but when different versions of messages require a different message structure, the converter handles this.

Now you will see that the PHP properties of Amadeus\Client\Struct\Ticket\CreateTSTFromPricing are a 100% match to the XML structure for this message that you will find in the Amadeus Web Services extranet for this message.

Now you just need to add extra code inside Amadeus\Client\Struct\Ticket\CreateTSTFromPricing to fill the properties of the Struct object so that it can be converted by PHP's SoapClient to the correct XML structure.

When you've done all that, you should be able to start testing the message. Be aware that the responses will always have status UNKNOWN until you implement a Response Handler.

Then there are a few more steps to be done:

• add a response handler which will check for errors in responses of the Amadeus Web Services (as mentioned above)
• add unittests
• add documentation
• add a changelog entry

---

So, to answer your questions:

how to identify which paramaters will be dynamic

What I usually do is examine the Amadeus Extranet page for this message and identify the different options available for a given message, and provide properties in my Request Options object to fill in each option that is available in the documentation (or just the ones you want to implement at first).

For our example: I have identified 2 options available in Ticket_CreateTSTFromPricing which I want to implement:

• A number of of pricings (which each have the properties TST number and an array of passenger numbers)
• an informational record locator parameter

So that's why I built the Amadeus\Client\RequestOptions\TicketCreateTstFromPricingOptions with the 2 properties that you can find in there.

how to pass those

I think the above explanation should explain how the Struct object receives Request Options should get you started to work this out.

The Amadeus\Client\Struct\Ticket\CreateTSTFromPricing class' constructor receives the Request Options object, and depending on which parameters were populated, the necessary XML structure is constructed.

---

I hope my answer is useful... If not, let me know.

[DerMika]

Were you able to implement this message? Any problems you've encountered?

[DerMika]

This message is now implemented on the master branch. Documentation here.

You can test it by switching your composer.json to dev-master. The message will be released with version 1.6.0.