x Want to participate? Join the group to interact
Options
  • State Verified Answer
  • Replies 3 replies
  • Subscribers 87 subscribers
  • Views 2171 views
  • Users 0 members are here
Browse Forums
Announcements
289
topics
370
replies
Business Object Interface
1k
topics
7k
replies
Core Financial Modules
2k
topics
8k
replies
Customization and Productivity
3k
topics
12k
replies
Distribution, Manufacturing, and Applications
2k
topics
7k
replies
General Discussion
1k
topics
3k
replies
Partner Cloud
43
topics
90
replies
Payroll, Time Tracking, and Job Cost
774
topics
1k
replies
Reporting and Analytics
960
topics
3k
replies
Sage CRM for Sage 100
164
topics
357
replies
Technical and Installation
2k
topics
9k
replies
Year-end Forum
89
topics
237
replies
SageAcolyte

NewObject Error: 200 error when deploy BOI insert order API, works fine on visual studio. However when deployed to web server, even local IIS, COMException (0x80020009): :<NewObject Error: 200>

SOLVED
Posted By

I have built an API that can insert orders into Sage 100. 

API will not work on when deployed to any IIS the web server, with a NewObject Error: 200 error.  This happens when I try to invoke SY_Session

I realized that this error occurs even on my local dev machine.  I can submit orders when in Visual studio but not when deployed, even to my local dev machine IIS

I can also deploy it to another live web server and a test web server with visual studio and it will not work on them at all.

The machine-default permission settings do not grant Local Activation permission for the COM Server application with CLSID
{60503AB4-2D27-11D6-B249-00C04F50D575}
and APPID
Unavailable
to the user IIS APPPOOL\OrderProcessAPI SID (S-1-5-82-1185196468-1477591131-2151125393-2588797397-3337611015) from address LocalHost (Using LRPC) running in the application container Unavailable SID (Unavailable). This security permission can be modified using the Component Services administrative tool.

Parents
  • +1
    verified answer

    In order to solve the deployment issue I was having:

    There was some configuration and some concessions I had to make. True, it is TLDR but I wanted to share the solution.

    Our publicly accessible web server is physically local to my workstation and our Sage ERP, but the webserver is on a different subnet AND it is not a member of the domain

    What I found is that with the .NET Core API, it has more restrictions than .NET Web API...

    Could NOT get it to communicate to Sage ERP BOI on the other subnet. I had to deploy it to another (internal) webserver that is not public, that is on the domain and the same subnet as the SQL database

    Also, and here is the key: I had to use a domain user for the APPLICATION POOL of the Core API. (A user on the same domain that Sage ERP is on)

    Following these changes, a call to the Core Api via a webpage served on the same domain and subnet as Sage ERP (and he Core Api) would work fine.

    Now, I simply have the app on our live web server call the internal APi, and it now can pass off the BOI to Sage

    Contrasted to Web Api, I would not be able to deploy this Core Api to a live webserver where it is not on the same domain as SAGE ERP. Well, ultimately this way is more secure, so this is good for this purpose.

Reply
  • +1
    verified answer

    In order to solve the deployment issue I was having:

    There was some configuration and some concessions I had to make. True, it is TLDR but I wanted to share the solution.

    Our publicly accessible web server is physically local to my workstation and our Sage ERP, but the webserver is on a different subnet AND it is not a member of the domain

    What I found is that with the .NET Core API, it has more restrictions than .NET Web API...

    Could NOT get it to communicate to Sage ERP BOI on the other subnet. I had to deploy it to another (internal) webserver that is not public, that is on the domain and the same subnet as the SQL database

    Also, and here is the key: I had to use a domain user for the APPLICATION POOL of the Core API. (A user on the same domain that Sage ERP is on)

    Following these changes, a call to the Core Api via a webpage served on the same domain and subnet as Sage ERP (and he Core Api) would work fine.

    Now, I simply have the app on our live web server call the internal APi, and it now can pass off the BOI to Sage

    Contrasted to Web Api, I would not be able to deploy this Core Api to a live webserver where it is not on the same domain as SAGE ERP. Well, ultimately this way is more secure, so this is good for this purpose.

Children
No Data

*Community Hub is the new name for Sage City