Error with : api/v1/Agents/Ticket/CreateDefaultTicketEntity

lock
push_pin
done
Answered
5

Hi

I first log a ticket to SuperOffice Support , but they sent me here. (since they does not handle API issues)

I have an onpremis environment where this endpoint does not work: POST operation
api/v1/Agents/Ticket/CreateDefaultTicketEntity 

Other endpoints work

api/v1/Agents/Ticket/CreateDefaultTicketMessageEntity - OK
api/v1/Agents/Contact/CreateDefaultContactEntity - OK

How can that be?
Customer running 10.1.6 (on Win Server 2012 R2)

I have tested the endpoint in 2 pther 10.1.6 environments and it does work there
The API tool Soap UI and postman say 403 Forbidden? 

In log I have found out:

Could not load file or assembly 'Microsoft.CodeAnalysis.Workspaces, Version=3.3.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.

Critical                2022-10-31T14:23:23.01           SuperOffice.Factory.TypeFactoriesCollection                                                        Unable to load one or more of the requested types from assembly. Missing dependencies? Failed to parse Assembly 'SuperOffice.CodeAnalyzer, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null',

Could not load file or assembly 'Microsoft.CodeAnalysis, Version=3.3.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.

Error                   2022-10-31T16:36:59.89           ServiceFacade                             CallServiceFacade Facade.List.GetTicketPriorityEntity Error {"ticketPriorityEntityId":2} <ReMOVED> (1) - Authorized (Employee)Behörighet 0: Administratör: Har fullständig tillgång till alla data. Kan administrera alla delar av systemet. Ticket.CreateDefault MSSQL - 12

Ticket prio table is default and looks ok to me.

Thankfull for some thoughts here, what to do?
Aperenttly something is wrong in this particular environment , but need some leed to try to solve it
//Anders

 

4 Nov 2022 | 08:38 AM

All Replies (5)

Have you tied to add the assembly that seems to be missing?

4 Nov 2022 | 08:51 AM

Those missing dependencies errors have nothing to do with it, that's just from missing dependencies from the SuperOffice.CodeAnalyzer, which is something internal for R&D and propably should not even be included in the OnSite release. You get that error everytime that CRM.web is loaded by the IIS application pool.

Are you sure that the encryptionKeys are setup correctly? the symmetricKey and symmetricSecret in the Service config file match the one's in the CRM.web web config file?

You could also try enabling the 'NewServiceAdmin' feature toggle, that will change the way this data is retrieved, instead of calling Service in the background (Service Facade), NetServer will retrieve the details from the database itself.

4 Nov 2022 | 09:18 AM

Hi,

I have solved this strange issue now..
Thanks King David! You lead me in the correct direction. 

The strange thing is that some endpoints did work but others like the CreateDefaultTicketEntity did not.

That did not lead me to suspect the symmetric keys. Did check the keys up and they were the same (but config saved in UTF8-BOM format)
Changed to regular UTF8 format , but still not working. 

I missed to tell that the environment uses a separate netserver for SO service.
The Service config file did now have the same symmetric Key / Secret as for that netserver. (That does not seem to be enoguh for all endpoints)

After making sure that the separate netServer for CS had the same symmetricKey/Secret as SO web(sales) and updating the service config-file the failing endpoint now works.

That was totally new to me that a separate netserver can not have its own symmetric Key / Secret. Eg the netserver used by SO Service and the built in netserver in Sales needs to use the same symmetric key and Secret to work 100% (it seems to work for motst of the endpoints anyway)

RND => can you explain what is going on here? Why does some endpoints fail while others does work when using a separate netserver for SO Service that has its own symmetric key / secret (used in config file). Is it by design or a bug?

Best regards
//Anders

 

 

 

7 Nov 2022 | 01:41 PM
Some API calls use the Service facade, which means that internally NetServer calls Service to perform the required actions, when NetServer internally calls Service it is required that the symmetric key/secret match.

Other API calls are purely performed in NetServer without an internal API call to Service, so that symmetric key/secret not matching is not an issue. Like I mentioned the feature toggle 'NewServerAdmin' control this for a few endpoints (like ticket priority)
7 Nov 2022 | 01:54 PM

Ok, thanks for the explanation David.

Will have look at the featue toggle, do you know when that will be default ?
So basiclly you are saying that with this newServerAdmin feature toggled => Pure Net Server calls would be used (and that is mainly how I thought i was working eg the specified netserver in config is allways used for all SO Service communication internally and via the API:s, and the symmetricKey/secret for specifed netserver should be used in config-file)


Do we have a list on endpoints and what method they use? Faccade vs pure Netserver

Best regards
//Anders

7 Nov 2022 | 02:05 PM
When 'NewServiceAdmin' feature toggle is enabled some endpoints will do pure NetServer calls instead of using the Service facade, it is not for all Service related endpoints. Which endpoints specifically use the Service Facade and when the feature toggle is going to be enabled is not (publicly) documented and more a question for R&D. If you have the symmetric key/secret configured correctly for all NetServer & Service instances it should not matter much anyway.
7 Nov 2022 | 02:35 PM

Ok, thanks again David!

I will from now on always use same SymmeticKey and SymmetricSecret for all extra netservers as used in the main installation of SO Sales.
R&D => Where can we find more information ariund this new feature toogle David is mentioning alongside with which endpoints is affected?

Does anyone know if service will be able to use https netserver anytime soon ?
that is one reason an extra netsever is needed if running the main SO Sales installation in https only mode (then SO Service cant use the built in netsever in SO Sales installation)

Best regards
//Anders

9 Nov 2022 | 09:53 AM
FeatureToggles are not something the product team advertises. It's not used to enable hidden features, it is use to hide things in development and not ready for customer outside pilot programs.
16 Nov 2022 | 11:44 AM

Add reply